On 05/03/2024 03:03, Peter 'Shaggy' Haywood wrote:
> Groovy hepcat jak was jivin' in comp.lang.c on Sat, 2 Mar 2024 12:49 pm.
> It's a cool scene! Dig it.
>
>> Kenny McCormack ha scritto:
>>> In article <urrj5l$124o9$1@dont-email.me>,
>>> Mike Sanders <porkchop@invalid.foo> wrote:
>>>> Just sharing what I've learned, hope some of you can adapt
>>>> it for your own use.
>>>>
>>>> Calculates the name of the weekday (Sun, Mon, etc) for the
>>>> 1st day of a given month & year...
>>>>
>>>> https://busybox.neocities.org/notes/get-first-day-of-month.txt
>>>
>>> Here's the guts of my version of the Zeller algorithm:
>>>
>>> int day(d,m,y)
>>> int d, m, y;
>>> {
>>> if (m < 3) {
>>> m += 12;
>>> y--;
>>> }
>>> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
>>
>> Hi,
>> I am referring in particular to this part of the equation:
>> y + y/4 - y/100 + y/400
>> Shouldn't it be calculated in a floating point and then truncated only
>> the final result? Because, for example, if the year is 2024, the
>> floating point calculation is 2514 (2514.82) while executed between
>> integer is 2515.
>
> No. The "+ y/4 - y/100 + y/400" part is adding a day for each leap
> year. You see, a leap year is divisible by 4, but is not divisible by
> 100, but is divisible by 400. So, it's adding the number of years
> divisible by 4, subtracting those divisible by 100 and adding those
> divisible by 400 to determine the number of leap days up to the given
> date.
> So often in the last week or two I've heard people (who ought to know
> better) on news programs on telly say that a leap year comes every 4
> years, and I want to beat them about the head with a humorous object of
> some kind until they get this right! A leap year does NOT come EVERY 4
> years.

For most practical purposes and for the lifetimes of most of the 8
billion people on the planet, leap years do come every four years.

That's the case for years 1901 to 2099.

What exactly do you expect those news readers that reach a massive
audience to do, get into those details of being divisible or not by 100
or 400? Maybe they should also mention odd years like 1752 where there
was a calendar reform for even more exceptions to the rule.

Half the audience probably barely know what a leap year is.

In article <20240301180259.118@kylheku.com>,
Kaz Kylheku <433-929-6894@kylheku.com> wrote:
....
>Pissing on new code using old-style C in 5... 4... 3....

Actually, the code in question says (according to the comments) that it
was written 12/10/99. I suppose even that is fairly modern (by the
standards of CLC newsgroup regs).

Obviously, the algorithm goes much further back than that.

See: https://en.wikipedia.org/wiki/Christian_Zeller

Julius Christian Johannes Zeller (24 June 1822, M�hlhausen am Neckar ? 31
May 1899, Cannstatt)

--
Modern Conservative: Someone who can take time out from demanding more
flag burning laws, more abortion laws, more drug laws, more obscenity
laws, and more police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".

porkchop@invalid.foo (Mike Sanders) writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> POSIX defines 0 as a successful status "for shell commmands", in
>> the context of this discussion.
>
>Sure enough & Keith as well. Cobbled together a simple solution
>just display more informative error messages as well as sticking
>to zero/one. This satisfies scripting in the unix world:
>
>[ dates -op1 -op2 file || echo no banana ]

One performance note about this.

'[' does a PATH lookup, finding a utility
(actually a link to the 'test' utility) followed by fork(2)
and exec(2)).

'[[' is built into the shell, so more efficient.

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-03-05, Mike Sanders <porkchop@invalid.foo> wrote:
>> Interesting stuff. The main thing with me is to (under Windows at least)
>> facilitate an easier way to use my tool in an automated way.
>>
>> The GetExitCodeProcess function documentation specifies that the ExitCode
>> is a "DWORD 32-bits integer". This means that from cmd.exe point of view
>> (remember, cmd.exe *is the primary interface* or shell under win):
>>
>> (emphasis mine)
>>
>> *****
>> an .exe program may return as %ERRORLEVEL% a value from -2147483648 to
>> 2147483647
>> *****
>
>Your reasoning is far from air tight here.
>
>Consider that on Unix, the exit system call takes an "int". Does that
>mean that any value from INT_MIN to INT_MAX will be passed through
>cleanly as a termination status?
>
>For monitoring the status of a child process, you can use waitpid.
>Again, that takes a pointer to an int.

POSIX also supports waitid() which does return the entire
'int' exit code.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 04.03.2024 19:26, Scott Lurndal wrote:
>> porkchop@invalid.foo (Mike Sanders) writes:
>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>
>>>> As someone who started using unix in an environment where there
>>>> was only one case, I find I prefer lower-case option
>>>> flags, simply because they're easier to type.
>>>>
>>>> (In the old days, to type upper-case characters on a teletype
>>>> required prefixing each upper-case character with a backslash
>>>> character - and the terminal driver would display uppercase
>>>> with the prefix).
>>>
>>> Wow, chuckle, really made you work hard for the results!
>>
>> It does explain why CamelCase never gained traction in Unix.
>
>You mean in Unix commands, or in the Unix source code,

Yes, much of which was written on a teletype originally.

I've seen plenty of camelcase in application code.

scott@slp53.sl.home (Scott Lurndal) writes:
> porkchop@invalid.foo (Mike Sanders) writes:
>>Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> POSIX defines 0 as a successful status "for shell commmands", in
>>> the context of this discussion.
>>
>>Sure enough & Keith as well. Cobbled together a simple solution
>>just display more informative error messages as well as sticking
>>to zero/one. This satisfies scripting in the unix world:
>>
>>[ dates -op1 -op2 file || echo no banana ]
>
> One performance note about this.
>
> '[' does a PATH lookup, finding a utility
> (actually a link to the 'test' utility) followed by fork(2)
> and exec(2)).
>
> '[[' is built into the shell, so more efficient.

'[' is typically both a shell builtin (in bash, ksh, zsh) and an
executable (/usr/bin/[ and/or /bin/[).

'[[', in shells where it exists, is a pure builtin and not also an
executable.

In any case, there's no reason to use '[' in the above command, and in
fact it's a syntax error. It may be a result of the common
misconception that '[' and ']' are part of the syntax of a shell 'if'
statement. The performance of '[' doesn't matter if it's being used
incorrectly.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Janis Papanagnou wrote:
> On 04.03.2024 18:34, Mike Sanders wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> The "problem" is that you may want to have -h as an option character,
>>> especially if your program supports a lot of options and you have no
>>> creative naming way of choosing another character. (An example from
>>> one of my recent implementations is using -h for 'height'.[*])
>>
>> This is my rationale as well: All of the switches have a more/or less
>> mnemonic feel -X (eXport), -H (Holiday), -C (Calendar), -M (Manual).
>>
>> I thought it made good sense at least.
>
> Yes, of course it does. Most software developers obviously try
> to choose memorable mnemonics. (Imagine we'd have -o1 -o2 -o3
> ..., or -a -b -c ..., as option interface design rules.)
>
> I wonder, though, my you've chosen letters in caps; I'd avoided
> the additional <shift> key press. (First I thought it might be
> some Windows/DOS restriction or so.)

From what I've seen, usage help for Windows commands typically shows
options in uppercase, although they tend to be interpreted
case-insensitively (just as file names are on Windows). Windows
utilities also typically use "/" rather than "-" to indicate options (at
least before PowerShell). So "-x" for a *nix utility would more
typically be "/X" for a Windows utility (but typing "/x" would also work).

It's also quite common for Windows utilities to use "/?" rather than
"/H" to get usage help, which might be where the "-?" idea came from
(which I think I saw somewhere earlier in this thread).

Of course, on both platforms, it's up to application code to interpret
the options passed on the command line. There's nothing to stop a
Windows utility from using "-x", or a *nix utility using "/X" - and a
utility ported from one platform to the other might stick with the
option style from the original platform. Using "/" to indicate options
on *nix might cause problems for anyone wanting to pass an absolute
path, though...

--
Mark.

Mark Bourne <nntp.mbourne@spamgourmet.com> writes:
>Janis Papanagnou wrote:
>> On 04.03.2024 18:34, Mike Sanders wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>
>>>> The "problem" is that you may want to have -h as an option character,
>>>> especially if your program supports a lot of options and you have no
>>>> creative naming way of choosing another character. (An example from
>>>> one of my recent implementations is using -h for 'height'.[*])
>>>
>>> This is my rationale as well: All of the switches have a more/or less
>>> mnemonic feel -X (eXport), -H (Holiday), -C (Calendar), -M (Manual).
>>>
>>> I thought it made good sense at least.
>>
>> Yes, of course it does. Most software developers obviously try
>> to choose memorable mnemonics. (Imagine we'd have -o1 -o2 -o3
>> ..., or -a -b -c ..., as option interface design rules.)
>>
>> I wonder, though, my you've chosen letters in caps; I'd avoided
>> the additional <shift> key press. (First I thought it might be
>> some Windows/DOS restriction or so.)
>
> From what I've seen, usage help for Windows commands typically shows
>options in uppercase, although they tend to be interpreted
>case-insensitively (just as file names are on Windows). Windows
>utilities also typically use "/" rather than "-" to indicate options (at
>least before PowerShell). So "-x" for a *nix utility would more
>typically be "/X" for a Windows utility (but typing "/x" would also work).

Ah, Powershell. The COBOL of scripting languages.
>
>It's also quite common for Windows utilities to use "/?" rather than
>"/H" to get usage help, which might be where the "-?" idea came from
>(which I think I saw somewhere earlier in this thread).

In my experience, the '-?' is derived from the getopt(3) semantics
where it returns the option character '?' for any undefined
option flags.

Which means that

switch (getopt(...)) {
case '?':
usage();
break;
}

handles both -? and any undefined flags.

bart ha scritto:
> For most practical purposes and for the lifetimes of most of the 8
> billion people on the planet, leap years do come every four years.
>
> That's the case for years 1901 to 2099.
>
> What exactly do you expect those news readers that reach a massive
> audience to do, get into those details of being divisible or not by 100
> or 400? Maybe they should also mention odd years like 1752 where there
> was a calendar reform for even more exceptions to the rule.
>
> Half the audience probably barely know what a leap year is.

You are right, but this usenet is followed by people, professionals and
computer enthusiasts. I would like to try to make a statistics but I
think at least 70% read somewhere how to determine if a year is a leap.
I, example, discovered this by writing my first management program in
Rmcobol almost 40 years ago.

jak ha scritto:
> bart ha scritto:
>> For most practical purposes and for the lifetimes of most of the 8
>> billion people on the planet, leap years do come every four years.
>>
>> That's the case for years 1901 to 2099.
>>
>> What exactly do you expect those news readers that reach a massive
>> audience to do, get into those details of being divisible or not by
>> 100 or 400? Maybe they should also mention odd years like 1752 where
>> there was a calendar reform for even more exceptions to the rule.
>>
>> Half the audience probably barely know what a leap year is.
>
>
> You are right, but this usenet is followed by people, professionals and
> computer enthusiasts. I would like to try to make a statistics but I
> think at least 70% read somewhere how to determine if a year is a leap.
> I, example, discovered this by writing my first management program in
> Rmcobol almost 40 years ago.

Instead, I would be curious to understand why nobody follows a standard
about the dates. Let's take this date for example: January 1, 1580.
On the web 50% of the sites searched with "day of week calculator" say
that the day was Tuesday while the others say it was Friday. Excel and
Calc (OpenOffice) say it was Friday and the same says "cal" on *nix if
the "--iso" option is not used. So, someone follows the ISO convention
and others Julian but I read somewhere that the ISO convention had to be
followed in the computer scope.

On Wed, 13 Mar 2024 06:01:22 +0100
jak <nospam@please.ty> wrote:
> Instead, I would be curious to understand why nobody follows a standard
> about the dates. Let's take this date for example: January 1, 1580.
> On the web 50% of the sites searched with "day of week calculator" say
> that the day was Tuesday while the others say it was Friday. Excel and
> Calc (OpenOffice) say it was Friday and the same says "cal" on *nix if
> the "--iso" option is not used. So, someone follows the ISO convention
> and others Julian but I read somewhere that the ISO convention had to be
> followed in the computer scope.

For the year 1580 what would be the appropriate standard ? I don't see any
point using a modern standard for 1580. The day of the week is a cultural
matter depending on era and location so what useful cultural information
would you get by knowing that according to a modern standard , January 1
1580 was whatever day ?

jak <nospam@please.ty> writes:
> jak ha scritto:
>> bart ha scritto:
>>> For most practical purposes and for the lifetimes of most of the 8
>>> billion people on the planet, leap years do come every four years.
>>>
>>> That's the case for years 1901 to 2099.
>>>
>>> What exactly do you expect those news readers that reach a massive
>>> audience to do, get into those details of being divisible or not by
>>> 100 or 400? Maybe they should also mention odd years like 1752
>>> where there was a calendar reform for even more exceptions to the
>>> rule.
>>>
>>> Half the audience probably barely know what a leap year is.
>>
>> You are right, but this usenet is followed by people, professionals and
>> computer enthusiasts. I would like to try to make a statistics but I
>> think at least 70% read somewhere how to determine if a year is a leap.
>> I, example, discovered this by writing my first management program in
>> Rmcobol almost 40 years ago.
>
> Instead, I would be curious to understand why nobody follows a standard
> about the dates. Let's take this date for example: January 1, 1580.
> On the web 50% of the sites searched with "day of week calculator" say
> that the day was Tuesday while the others say it was Friday. Excel and
> Calc (OpenOffice) say it was Friday and the same says "cal" on *nix if
> the "--iso" option is not used. So, someone follows the ISO convention
> and others Julian but I read somewhere that the ISO convention had to be
> followed in the computer scope.

Where did you read that? ISO has no police force. Anyone writing a
program or a web page can do whatever they like. Sure, some things you
can do with a web page might be illegal, but using a non-ISO calendar
standard isn't one of them.

As you probably know, the transition from the Julian to the Gregorian
calendar happened at different times in different parts of the world:
1582 in Roman Catholic countries, 1752 in Britain and its posessions
(including what later became the US), and as late as the 1920s in some
places. (The "cal" command on my system has no "--iso" option.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Spiros Bousbouras <spibou@gmail.com> writes:
> On Wed, 13 Mar 2024 06:01:22 +0100
> jak <nospam@please.ty> wrote:
>> Instead, I would be curious to understand why nobody follows a standard
>> about the dates. Let's take this date for example: January 1, 1580.
>> On the web 50% of the sites searched with "day of week calculator" say
>> that the day was Tuesday while the others say it was Friday. Excel and
>> Calc (OpenOffice) say it was Friday and the same says "cal" on *nix if
>> the "--iso" option is not used. So, someone follows the ISO convention
>> and others Julian but I read somewhere that the ISO convention had to be
>> followed in the computer scope.
>
> For the year 1580 what would be the appropriate standard ? I don't see any
> point using a modern standard for 1580. The day of the week is a cultural
> matter depending on era and location so what useful cultural information
> would you get by knowing that according to a modern standard , January 1
> 1580 was whatever day ?

There's something called the proleptic Gregorian calendar, produced by
extending the rules for the Gregorian calendar back to dates preceding
its introduction. It's used fairly widely.

https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar

Note also that in the US consider George Washington's birthday is
considered to be February 22 (NS, new style), even though that date was
February 11 (OS) under the Julian calender then in effect.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> Note also that in the US consider George Washington's birthday is
> considered to be February 22 (NS, new style), even though that date was
> February 11 (OS) under the Julian calender then in effect.

Some day I'll learn to re-read after editing and avoid word jumbles like
the above.

Note also that in the US George Washington's birthday is considered to
be February 22 (NS, new style), even though that date was February 11
(OS) under the Julian calender then in effect.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 4 Mar 2024 21:21:25 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
[...]
>> If you want to /guarantee/ that the return value of strcmp()
>> is -1, 0, or +1 (for "less than", "equal to", or "greater than")
>> you will have to process the return value with something like
>>
>> /*
>> ** Returns -1 if argument < 0, 0 if argument == 0, 1 if argument > 0
>> */
>> int iSignOf(int valu)
>> {
>> return ((valu > 0) - (valu < 0));
>> }
>
> Too tricky to my liking.
> I'd rather write straight-forward code and let compiler to figure
> out the best sequence.
>
> int iSignOf(int val)
> {
> if (val < 0)
> return -1;
> if (val > 0)
> return +1;
> return 0;
> }

I've seen the idiomatic form before, and my reaction to it is
more of it being overly cute than overly tricky. That said,
it is a bit on the tricky side; even so, I'm not sure the cure
suggested is much better than the disease. I would simply write
a single return statement:

return val < 0 ? -1 : val > 0 ? 1 : 0;

(possibly condensed to take advantage of the 0/1 result of the
"greater than" operator for non-negative operands).

I suppose some people prefer the multiple return form to the ?:
form, although I'm not sure why except perhaps as a carryover
from earlier experience.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> jak <nospam@please.ty> writes:

[about different date formats]

>> So, someone follows the ISO convention and others Julian but I
>> read somewhere that the ISO convention had to be followed in the
>> computer scope.
>
> Where did you read that? ISO has no police force. [...]

Note that there are organizations that mandate compliance with
some ISO standards under certain circumstances even though the
organizations themselves have no direct relationship with ISO.