Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #383208 > unrolled thread

getFirstDayOfMonth()

Back to article view | Back to comp.lang.c

Contents

  getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 03:48 +0000
    Re: getFirstDayOfMonth() gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-01 15:39 +0000
      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:12 +0100
        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-01 08:28 -0800
          Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:33 +0100
            Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:37 +0100
              Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-01 10:34 -0800
                Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 22:03 +0100
          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 17:20 +0000
      Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-01 16:47 +0000
      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 17:56 +0100
      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 17:18 +0000
      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 20:47 +0000
        Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-01 21:38 +0000
          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-01 21:50 +0000
            Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 09:52 -0800
          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-02 00:00 +0000
            Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-02 14:46 +0000
              Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-02 16:41 +0100
              Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-02 19:59 +0000
                Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-02 22:14 +0100
                  Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 18:08 +0000
                    Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:03 +0100
                Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-02 14:22 -0800
                  Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-03 15:43 +0100
                    Re: getFirstDayOfMonth() David Brown <david.brown@hesbynett.no> - 2024-03-03 18:45 +0100
                      Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-03 18:42 +0000
                        Re: getFirstDayOfMonth() David Brown <david.brown@hesbynett.no> - 2024-03-04 09:49 +0100
                      Re: getFirstDayOfMonth() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-04 11:31 +0000
                        Re: getFirstDayOfMonth() Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-04 14:23 +0000
                      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-04 17:27 +0100
                    Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 17:34 +0000
                      Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 17:40 +0000
                        Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 18:11 +0000
                          Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 18:26 +0000
                            Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-04 18:30 +0000
                              Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 19:01 +0000
                            Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:09 +0100
                              Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:06 +0000
                      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 02:56 +0100
                        Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:49 +0000
                        Re: getFirstDayOfMonth() Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-03-06 20:40 +0000
                          Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-06 20:54 +0000
                  Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 17:26 +0000
                    Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 17:34 +0000
                      Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 10:07 -0800
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 23:47 +0000
                        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 16:10 -0800
                        Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 00:12 +0000
                          [OT] Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:18 +0100
                            Re: [OT] Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:55 +0000
                        Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:03 +0000
                          Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-05 13:25 -0800
                    Re: getFirstDayOfMonth() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-03-04 21:21 +0000
                      Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-05 00:37 +0200
                        Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-05 11:41 +0200
                        Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 15:57 -0700
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 23:35 +0000
                      Re: getFirstDayOfMonth() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:20 +0100
                Re: getFirstDayOfMonth() James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-03 04:06 -0500
                  Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-04 18:21 +0000
                    Re: getFirstDayOfMonth() James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-04 14:42 -0500
                    Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 14:50 -0800
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 00:40 +0000
                        Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-05 01:27 +0000
                          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:40 +0000
                          Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:05 +0000
                        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 17:39 -0800
                          Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 02:43 +0000
                    Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-05 01:08 +0200
                      Re: getFirstDayOfMonth() porkchop@invalid.foo (Mike Sanders) - 2024-03-05 00:18 +0000
                        Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 16:33 -0800
                Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-03 15:24 +0000
                  Re: getFirstDayOfMonth() Michael S <already5chosen@yahoo.com> - 2024-03-03 20:20 +0200
                    Re: getFirstDayOfMonth() scott@slp53.sl.home (Scott Lurndal) - 2024-03-03 18:56 +0000
              Re: getFirstDayOfMonth() Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-03-03 13:17 +0000
      Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-02 02:49 +0100
        Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 09:47 -0800
          Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-04 02:26 +0100
        Re: getFirstDayOfMonth() Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-03-05 14:03 +1100
          Re: getFirstDayOfMonth() bart <bc@freeuk.com> - 2024-03-05 13:19 +0000
            Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-13 05:40 +0100
              Re: getFirstDayOfMonth() jak <nospam@please.ty> - 2024-03-13 06:01 +0100
                Re: getFirstDayOfMonth() Spiros Bousbouras <spibou@gmail.com> - 2024-03-13 13:38 +0000
                  Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 08:47 -0700
                    Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 09:11 -0700
                Re: getFirstDayOfMonth() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 07:36 -0700
                  Re: getFirstDayOfMonth() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 19:56 -0700
      Re: getFirstDayOfMonth() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-02 03:44 +0000
        Re: getFirstDayOfMonth() Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-03-05 14:07 +1100
        Re: getFirstDayOfMonth() gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-05 13:30 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#383317

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> The lack of nuance is apparently the result of your being unaware of the
> fact that 1 is not the only permitted error return.
> 
> Keep in mind that the make utility and shells designed for Unix-like
> systems (as well as many other programs targeting such systems) expect 0
> for success, and may produce unexpected results if you violate that
> convention.

Not at all, what the shell accepts as success under unix, is not the
same under windows. The convention is OS specific, everyone here tends
to think only in terms of POSIX & $SHELL & yet, there are other worlds
out there...

:: comment

@echo off & cls

if %errorlevel% EQU 1000 (

    echo successful as defined by my needs not yours

)

-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383322

On 3/4/24 13:21, Mike Sanders wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> The lack of nuance is apparently the result of your being unaware of the
>> fact that 1 is not the only permitted error return.
>>
>> Keep in mind that the make utility and shells designed for Unix-like
>> systems (as well as many other programs targeting such systems) expect 0
>> for success, and may produce unexpected results if you violate that
>> convention.
>
> Not at all, what the shell accepts as success under unix, is not the
> same under windows.

I was talking about the problems you would have with ignoring that
convention on Unix-like systems, which I'm very familiar with, I had no
intention of giving advice relevant to other operating systems. The need
to do different things on different operating systems is part of the
reason why the EXIT_SUCCESS and EXIT_FAILURE macros exist, but that only
scratches the surface of what needs to be done for portability.
If your program needs to be portable to POSIX systems, it needs to have
a mode that returns 0 on success, regardless of what it does on any
other operating system.

[toc] | [prev] | [next] | [standalone]

#383336

porkchop@invalid.foo (Mike Sanders) writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> The lack of nuance is apparently the result of your being unaware of the
>> fact that 1 is not the only permitted error return.
>> 
>> Keep in mind that the make utility and shells designed for Unix-like
>> systems (as well as many other programs targeting such systems) expect 0
>> for success, and may produce unexpected results if you violate that
>> convention.
>
> Not at all, what the shell accepts as success under unix, is not the
> same under windows. The convention is OS specific, everyone here tends
> to think only in terms of POSIX & $SHELL & yet, there are other worlds
> out there...
>
> :: comment
>
> @echo off & cls
>
> if %errorlevel% EQU 1000 (
>
>     echo successful as defined by my needs not yours
>
> )

Sure, you can write a script that assumes 1000 indicates success -- but
it's just as non-idiomatic on Windows as on POSIX systems.  (POSIX only
supports values from 0 to 255.)

    some_command
    if [ $? = 100 ] ; then
        echo SUCCESS
    else
        echo FAILURE
    fi

But Windows, like POSIX, has a convention than an exit code of zero
denotes success, and non-zero denotes an error.  The convention probably
isn't as hardwired into the system on Windows as it is on POSIX, but
it's there.

For example, the documentation for the C# Environment.Exit() function
says "Use 0 (zero) to indicate that the process completed
successfully.".  Windows cmd (the command that runs batch files) has a
special syntax in its "if" statement that tests the value of
%errorlevel; "if errorlevel 1" is used to test if the errorlevel is 1 or
greater, i.e., denotes failure.

VMS (officially OpenVMS) uses 1 to denote success, which is why exit(0)
in a VMS C program sets the system status to 1, not 0.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#383345

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

> Sure, you can write a script that assumes 1000 indicates success -- but
> it's just as non-idiomatic on Windows as on POSIX systems.  (POSIX only
> supports values from 0 to 255.)
> 
>     some_command
>     if [ $? = 100 ] ; then
>         echo SUCCESS
>     else
>         echo FAILURE
>     fi
> 
> But Windows, like POSIX, has a convention than an exit code of zero
> denotes success, and non-zero denotes an error.  The convention probably
> isn't as hardwired into the system on Windows as it is on POSIX, but
> it's there.
> 
> For example, the documentation for the C# Environment.Exit() function
> says "Use 0 (zero) to indicate that the process completed
> successfully.".  Windows cmd (the command that runs batch files) has a
> special syntax in its "if" statement that tests the value of
> %errorlevel; "if errorlevel 1" is used to test if the errorlevel is 1 or
> greater, i.e., denotes failure.
> 
> VMS (officially OpenVMS) uses 1 to denote success, which is why exit(0)
> in a VMS C program sets the system status to 1, not 0.

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
*****

So... yeah. I mean, I would rather leverage that force multiplier than not.

-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383346

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.

That int is not simply an exit code. It can indicate whether the
process terminated successfully or abnormally (due to a fatal signal),
and if abnormally, which signal. There are portable C macros for 
obtaining this information, like WIFEXITED and whatnot.

In the Microsoft exit code case, the docuumentation says:

  This function returns immediately. If the process has not terminated
  and the function succeeds, the status returned is STILL_ACTIVE (a
  macro for STATUS_PENDING (minwinbase.h)). If the process has
  terminated and the function succeeds, the status returned is one of
  the following values:

  - The exit value specified in the ExitProcess or TerminateProcess
    function.

  - The return value from the main or WinMain function of the process.

  - The exception value for an unhandled exception that caused the
    process to terminate.

So while you could use any value in the DWORD range, some of the values would
be confused for STILL_ACTIVE, STATUS_PENDING, or might look like the
code of an unhandled exception (I'm guessing 0xCxxxxxxx? Or are therere
others).  If you don't want to know what all those are, and don't require
a vast range of exit statuses, your best bet is probably to stick to
small, nonnegative integers.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#383356

Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> Your reasoning is far from air tight here.

Hey-hey Kaz! But I've got a simple way...

> For monitoring the status of a child process, you can use waitpid.
> Again, that takes a pointer to an int.

For threaded stuff & children I'm actually not sure. Was under the
impression that the parent's return value was defacto, YMMV.

> So while you could use any value in the DWORD range, some of the values would
> be confused for STILL_ACTIVE, STATUS_PENDING, or might look like the
> code of an unhandled exception (I'm guessing 0xCxxxxxxx? Or are therere
> others).  If you don't want to know what all those are, and don't require
> a vast range of exit statuses, your best bet is probably to stick to
> small, nonnegative integers.

Here's the way I'm handling it (the error code debate), because the app
I'm working is a subsystem exe (console only in this case as you know),
I don't have WinMain(), & a confounded message pump (so never need to
filter WM_CLOSE, WM_DESTROY, etc) no manifest, no packed icons (multiple
icons are required now - ugh) & all the rest, just plain-jane main() &
am happily (mercifully?) insulated from several layers of abstraction.
That & limiting myself to a range, likely the real secret sauce...

class 3 errors: 300x
class 2 errors: 200x
class 1 errors: 100x

So 3 cheers for subsystem exes' small & quick. but hey, I'm getting close
rankling the other guys so I'll let it be.

Saw your page too at: https://www.kylheku.com/~kaz/

You're a very creative guy, keep on keepin' on =)

-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383390

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.

[toc] | [prev] | [next] | [standalone]

#383347

porkchop@invalid.foo (Mike Sanders) writes:
[...]
> 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
> *****
>
> So... yeah. I mean, I would rather leverage that force multiplier than not.

Why?

Sure, assuming %ERRORLEVEL% can really take on any integer value from
-2147483648 to +2147483647 (I don't know whether it can), you can write
Windows-specific code that takes full advantage of that range.

Do you really have a requirement to use that full range?  Do you have
several billion distinct error conditions that you want to report?  Or
are you using %ERRORLEVEL% as some kind of counter?  You've only shown
us 4 distinct error conditions for the tool we were discussing.

On POSIX, "$?" is restricted to the range 0 to 255.  Do you really need
more than 256 distinct status codes?  (The most I've seen in any common
command is less than 100, for curl, and that's a rather extreme
outlier.)

If you don't care about portability to non-Windows systems, that's fine,
but then there are better places to discuss your requirements.

The C standard doesn't guarantee more than 0, EXIT_SUCCESS (which is
usually equal to 0), and EXIT_FAILURE.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#383357

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

> Why?
> 
> Sure, assuming %ERRORLEVEL% can really take on any integer value from
> -2147483648 to +2147483647 (I don't know whether it can), you can write
> Windows-specific code that takes full advantage of that range.
> 
> Do you really have a requirement to use that full range?  Do you have
> several billion distinct error conditions that you want to report?  Or
> are you using %ERRORLEVEL% as some kind of counter?  You've only shown
> us 4 distinct error conditions for the tool we were discussing.
> 
> On POSIX, "$?" is restricted to the range 0 to 255.  Do you really need
> more than 256 distinct status codes?  (The most I've seen in any common
> command is less than 100, for curl, and that's a rather extreme
> outlier.)
> 
> If you don't care about portability to non-Windows systems, that's fine,
> but then there are better places to discuss your requirements.
> 
> The C standard doesn't guarantee more than 0, EXIT_SUCCESS (which is
> usually equal to 0), and EXIT_FAILURE. 

Its no big deal Keith =) I'll let it ride, but earnest thanks for all
your help.

-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383338

On Mon, 4 Mar 2024 18:21:06 -0000 (UTC)
porkchop@invalid.foo (Mike Sanders) wrote:

> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> 
> > The lack of nuance is apparently the result of your being unaware
> > of the fact that 1 is not the only permitted error return.
> > 
> > Keep in mind that the make utility and shells designed for Unix-like
> > systems (as well as many other programs targeting such systems)
> > expect 0 for success, and may produce unexpected results if you
> > violate that convention.  
> 
> Not at all, what the shell accepts as success under unix, is not the
> same under windows. The convention is OS specific, everyone here tends
> to think only in terms of POSIX & $SHELL & yet, there are other worlds
> out there...
> 
> :: comment
> 
> @echo off & cls
> 
> if %errorlevel% EQU 1000 (
> 
>     echo successful as defined by my needs not yours
> 
> )
> 

However all Microsoft-supplied utilities as well as most (all ?)
built-in commands of their shells , like 'copy' or 'move', follow Unix
conventions for exit codes.

[toc] | [prev] | [next] | [standalone]

#383343

Michael S <already5chosen@yahoo.com> wrote:

> However all Microsoft-supplied utilities as well as most (all ?)
> built-in commands of their shells , like 'copy' or 'move', follow Unix
> conventions for exit codes.

Well, maybe not so much in practice as in theory, witness...

cmd /c exit -1073741510

-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383344

porkchop@invalid.foo (Mike Sanders) writes:
> Michael S <already5chosen@yahoo.com> wrote:
>> However all Microsoft-supplied utilities as well as most (all ?)
>> built-in commands of their shells , like 'copy' or 'move', follow Unix
>> conventions for exit codes.
>
> Well, maybe not so much in practice as in theory, witness...
>
> cmd /c exit -1073741510

I'm not sure what your point is.  Of course if a command lets you
specify a particular error code, it will use that error code regardless
of any conventions.  Or is your point that Windows supports a wider
range of error codes than POSIX does?

Windows follows the Unix convention of commands returning an exit status
of zero for success, non-zero for failure.  I don't know why you're so
determined to fight against that point.  There are differences in the
details (and better places to discuss them).  Status values in the range
0..255 are likely to be reasonably portable across POSIX and Windows
systems.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#383261

porkchop@invalid.foo (Mike Sanders) writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> If I may suggest:
>> 
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>> 
>> '-h'  or '-?' have traditionally been used to display
>> usage information for an utility.
>
>Yep, it will definitely be '-?' (still working to finalize things).
>
>Many thanks for the link too btw.
> 
>>>Error levels returned:
>>>
>>>3  Option syntax errors
>>>2  File open-read errors
>>>1  Dates match today or matching tags
>>>0  No dates match today or no tags match
>> 
>> For commands defined by POSIX (and generally in
>> unix), an exit status of zero indicates success.
>
>Oh yeah. Have been wrestling with the potential
>consequences of this for a good while. I think I'm
>going leave it as is because, (only speaking for
>myself here) the POSIX 0 good, 1 bad is terrible.

The reason posix commands return zero for success
is because the posix (and all other shells)
check the exit status of a command and treat
non-zero values as failure.

$ grep 'sigdelset' asim.cpp
$ echo $?
1
$ grep 'sigaddset' asim.cpp
    sigaddset(&signals, SIGHUP);
    sigaddset(&signals, SIGABRT);
    sigaddset(&signals, SIGPIPE);
    sigaddset(&signals, SIGUSR1);
    sigaddset(&signals, SIGUSR2);
    sigaddset(&sa.sa_mask, SIGHUP);
    sigaddset(&sa.sa_mask, SIGINT);
    sigaddset(&sa.sa_mask, SIGQUIT);
    sigaddset(&sa.sa_mask, SIGTERM);
    sigaddset(&sa.sa_mask, SIGXCPU);
$ echo $?
0

if grep -q 'sigaddset' asim.cpp
then
   echo "Found it!"
fi

>This is perhaps the only area I've ever seen where
>other OSs, like Windows, have a superior methodology
>on the issue. 0/1 provides next to no nuance. But
>I'm no expert, just my experience.

It's not 0/1, it is 0 for success and non-zero for
failure, where the failure is indicated by the
exit value (often restricted to 8-bits due to
the legacy wait(2) system call, however the
newer (for some value of new) system call waitid(2)
supports the full 32-bit exit status).

For example, the grep command returns
 0 - success
 1 - No lines were matched/selected
 >1 - An error occurred. 

Some utilities define additional exit status values.

VMS defined '1' (SS$_NORMAL) as the success return
value from system calls and commands, which is likely
the source of that feature in windows.

I've yet to find any feature of windows that is truely
superior (rather than just different).

[toc] | [prev] | [next] | [standalone]

#383268

On Sun, 03 Mar 2024 15:24:29 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> porkchop@invalid.foo (Mike Sanders) writes:
> >Scott Lurndal <scott@slp53.sl.home> wrote:
> >  
> >> If I may suggest:
> >> 
> >> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
> >> 
> >> '-h'  or '-?' have traditionally been used to display
> >> usage information for an utility.  
> >
> >Yep, it will definitely be '-?' (still working to finalize things).
> >
> >Many thanks for the link too btw.
> >   
> >>>Error levels returned:
> >>>
> >>>3  Option syntax errors
> >>>2  File open-read errors
> >>>1  Dates match today or matching tags
> >>>0  No dates match today or no tags match  
> >> 
> >> For commands defined by POSIX (and generally in
> >> unix), an exit status of zero indicates success.  
> >
> >Oh yeah. Have been wrestling with the potential
> >consequences of this for a good while. I think I'm
> >going leave it as is because, (only speaking for
> >myself here) the POSIX 0 good, 1 bad is terrible.  
> 
> The reason posix commands return zero for success
> is because the posix (and all other shells)
> check the exit status of a command and treat
> non-zero values as failure.
> 
> $ grep 'sigdelset' asim.cpp
> $ echo $?
> 1
> $ grep 'sigaddset' asim.cpp
>     sigaddset(&signals, SIGHUP);
>     sigaddset(&signals, SIGABRT);
>     sigaddset(&signals, SIGPIPE);
>     sigaddset(&signals, SIGUSR1);
>     sigaddset(&signals, SIGUSR2);
>     sigaddset(&sa.sa_mask, SIGHUP);
>     sigaddset(&sa.sa_mask, SIGINT);
>     sigaddset(&sa.sa_mask, SIGQUIT);
>     sigaddset(&sa.sa_mask, SIGTERM);
>     sigaddset(&sa.sa_mask, SIGXCPU);
> $ echo $?
> 0
> 
> if grep -q 'sigaddset' asim.cpp
> then
>    echo "Found it!"
> fi
> 
> >This is perhaps the only area I've ever seen where
> >other OSs, like Windows, have a superior methodology
> >on the issue. 0/1 provides next to no nuance. But
> >I'm no expert, just my experience.  
> 
> It's not 0/1, it is 0 for success and non-zero for
> failure, where the failure is indicated by the
> exit value (often restricted to 8-bits due to
> the legacy wait(2) system call, however the
> newer (for some value of new) system call waitid(2)
> supports the full 32-bit exit status).
> 
> For example, the grep command returns
>  0 - success
>  1 - No lines were matched/selected
>  >1 - An error occurred.   
> 
> Some utilities define additional exit status values.
> 
> VMS defined '1' (SS$_NORMAL) as the success return
> value from system calls and commands, which is likely
> the source of that feature in windows.
> 

Source of what feature in Windows?
Windows does not care too much about exit code, but to the level it
does care it follows the same conventions as Unix.

> I've yet to find any feature of windows that is truely
> superior (rather than just different).

How about F8 in cmd.exe shell?
Is not it non-trivially better than Crrl-r ?

[toc] | [prev] | [next] | [standalone]

#383271

Michael S <already5chosen@yahoo.com> writes:
>On Sun, 03 Mar 2024 15:24:29 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>

>
>> I've yet to find any feature of windows that is truely
>> superior (rather than just different).
>
>How about F8 in cmd.exe shell?
>Is not it non-trivially better than Crrl-r ?

I have no idea what F8 does in cmd.exe.

Or crrl-r.

[toc] | [prev] | [next] | [standalone]

#383258

Scott Lurndal wrote:
> porkchop@invalid.foo (Mike Sanders) writes:
>> Error levels returned:
>>
>> 3  Option syntax errors
>> 2  File open-read errors
>> 1  Dates match today or matching tags
>> 0  No dates match today or no tags match
> 
> For commands defined by POSIX (and generally in
> unix), an exit status of zero indicates success.

Also on Windows, an exit status of zero indicates success and non-zero 
failure.  From a command prompt, the status of the last command can be 
accessed via the %ERRORLEVEL% environment variable (similar to $? on *nix).

-- 
Mark.

[toc] | [prev] | [next] | [standalone]

#383237

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.

> }
> 
> I assume the two versions end up being equivalent.
> 
> BTW, how long do you think it will be until this thread gets hijacked into
> a long, acrimonious debate about what the definition of the first day of
> the month is and how various cultures define it differently, and how
> insensitive we are (especially, if "we" are USA Americans) to assume that
> our way is the only way?  A matter of hours, I suspect.
> 

[toc] | [prev] | [next] | [standalone]

#383264

jak <nospam@please.ty> writes:

> 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;
>
> 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.

The short answer is No.  If you try some examples I expect
you will see that using integer division always gives
correct results.  Leap days always happen in integer amounts,
so integer division is the right way to calculate them.

Note:  I haven't tested this particular algorithm and so
cannot vouch for its correctness.  But the part that
determines an extra number of days based on what year
it is matches other algorithms that I have tested.

[toc] | [prev] | [next] | [standalone]

#383293

Tim Rentsch ha scritto:
> jak <nospam@please.ty> writes:
> 
>> 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;
>>
>> 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.
> 
> The short answer is No.  If you try some examples I expect
> you will see that using integer division always gives
> correct results.  Leap days always happen in integer amounts,
> so integer division is the right way to calculate them.
> 
> Note:  I haven't tested this particular algorithm and so
> cannot vouch for its correctness.  But the part that
> determines an extra number of days based on what year
> it is matches other algorithms that I have tested.
> 

Thank you

[toc] | [prev] | [next] | [standalone]

#383384

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.

-- 


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
              Ain't I'm a dawg!!

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web