Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #120928 > unrolled thread
| Started by | wij <wyniijj5@gmail.com> |
|---|---|
| First post | 2024-11-20 11:02 +0800 |
| Last post | 2025-02-15 16:21 -0800 |
| Articles | 20 on this page of 92 — 19 participants |
Back to article view | Back to comp.lang.c++
Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 11:02 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-20 09:22 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 08:27 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:47 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 15:05 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 15:45 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 16:41 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 13:37 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 22:11 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 14:33 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 23:03 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:57 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:58 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:43 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-21 16:07 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 17:55 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-22 09:30 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-22 11:10 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@dastardlyhq.com - 2024-11-23 11:36 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:26 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-22 12:49 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-22 23:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-23 13:07 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 13:55 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 20:57 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-22 09:55 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:21 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:57 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:31 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:36 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 16:53 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-24 12:57 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:03 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-26 12:21 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 16:23 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-27 08:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 18:48 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 15:39 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:54 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 17:24 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 16:12 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-27 13:00 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:23 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:06 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 08:08 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:58 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 19:46 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:03 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 12:15 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:36 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 14:12 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 07:50 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:19 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:12 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 17:36 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-28 16:43 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:59 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-28 10:19 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 22:41 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 00:21 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-29 00:59 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 01:20 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-28 17:18 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 19:01 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:22 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 11:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:57 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:54 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:27 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 15:30 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 18:32 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-25 14:15 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 21:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:26 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:20 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-20 17:32 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? red floyd <no.spam.here@its.invalid> - 2024-11-20 22:56 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:51 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:44 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 22:57 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-20 17:23 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:09 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-21 22:45 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-25 22:20 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-11-26 10:20 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-30 16:52 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Andrey Tarasevich <noone@noone.net> - 2025-02-15 16:21 -0800
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-29 00:21 +0200 |
| Message-ID | <20241129002148.00002e56@yahoo.com> |
| In reply to | #121063 |
On Thu, 28 Nov 2024 22:41:42 +0200 Paavo Helde <eesnimi@osa.pri.ee> wrote: > On 28.11.2024 15:19, Michael S wrote: > > On Thu, 28 Nov 2024 13:03:20 +0200 > > Paavo Helde <eesnimi@osa.pri.ee> wrote: > > > >> On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: > >>> On Wed, 27 Nov 2024 14:58:18 -0500 > >>> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: > >>>> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: > >>>>> On Wed, 27 Nov 2024 17:24:05 +0200 > >>>>> Michael S <already5chosen@yahoo.com> wibbled: > >>>> .... > >>>>>> It works, but badly rather than fine. > >>>>>> Specifically, it works only with ASCII paths. Which, on > >>>>>> Windows, happen to be 2nd class. The biggest problem with > >>>>>> ASCII paths on Windows is > >>>>> > >>>>> How can ascii paths be 2nd class (whatever that means) given > >>>>> that ascii is a subset of utf-8? > >>>> > >>>> Because ascii is a subset of utf-8, any path name that contains a > >>>> character not in that subset cannot be represented, which is what > >>>> makes them 2nd class. > >>> > >>> Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd > >>> class. The only issue comes when some idiot tries to mix utf-8 > >>> with 8 bit ascii code pages. > >> > >> You are right, ASCII is not 2nd class because it is part of UTF-8. > >> It is 2nd class on Windows because MS have historically decided to > >> not support UTF-8 properly on Windows, in an attempt of a futile > >> vendor lock-in. > >> > > > > Not sure that it was about lock in. At time Win32 was conceived, > > UTF8 didn't exist. At time WinNt was shipped, it still was less > > than a year old. Back then choosing UTF16 looked reasonable. > > Up to ~15 years ago it was not clear that UTF8 not just won, but won > > decisively, so siting on the fence, waiting for the outcome of the > > battle and rooting for legacy was not totally unreasonable. For what > > happened after that, you could not underestimated a factor of > > laziness. > >> Though this is changing now, I just ran a quick test and apparently > >> calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with > >> VS2022 on Windows 10 and I can pass UTF-8 filenames to > >> narrow-string fopen() and they work properly. So there is progress! > >> > > > > Can you try it with paths that are longer than 260 characters? Both > > prefixed with "\\?\" and non-prefixed? > > > > Non-prefixed, _mkdir() succeeds with a path of 247 unicode characters > (406 bytes) and fails with 307 unicode chars (506 bytes). > > Prefixed with "\\?\" _mkdir() and fopen() appeared to work fine, > tried up to 1275 unicode chars (2114 bytes), the largest path was: > > \\?\C:\Tmp\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää.txt > > > > > Alas, the File Explorer left-hand tree failed to descend into so deep > directory tree (double-click in right-hand pane worked, but left-hand > tree was truncated at some point). When opened in Notepad or > Notepad++, the too long paths were changed into tilde-style "short > names", stripping the unicode chars: > > C:\tmp\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1.TXT > > > Prefixed Unicode is expected to work fine. Documentation is clear about it. I was wondering about behavior of prefixed ASCII. I.e. fopen() with default locale. My short test with VS2019 appears to work fine on Win7. So far I didn't try to dig deeper.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-11-29 00:59 +0200 |
| Message-ID | <viask1$o2bs$1@dont-email.me> |
| In reply to | #121065 |
On 29.11.2024 00:21, Michael S wrote: > On Thu, 28 Nov 2024 22:41:42 +0200 > Paavo Helde <eesnimi@osa.pri.ee> wrote: > >> On 28.11.2024 15:19, Michael S wrote: >>> On Thu, 28 Nov 2024 13:03:20 +0200 >>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>> >>>> On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: >>>>> On Wed, 27 Nov 2024 14:58:18 -0500 >>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >>>>>> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: >>>>>>> On Wed, 27 Nov 2024 17:24:05 +0200 >>>>>>> Michael S <already5chosen@yahoo.com> wibbled: >>>>>> .... >>>>>>>> It works, but badly rather than fine. >>>>>>>> Specifically, it works only with ASCII paths. Which, on >>>>>>>> Windows, happen to be 2nd class. The biggest problem with >>>>>>>> ASCII paths on Windows is >>>>>>> >>>>>>> How can ascii paths be 2nd class (whatever that means) given >>>>>>> that ascii is a subset of utf-8? >>>>>> >>>>>> Because ascii is a subset of utf-8, any path name that contains a >>>>>> character not in that subset cannot be represented, which is what >>>>>> makes them 2nd class. >>>>> >>>>> Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd >>>>> class. The only issue comes when some idiot tries to mix utf-8 >>>>> with 8 bit ascii code pages. >>>> >>>> You are right, ASCII is not 2nd class because it is part of UTF-8. >>>> It is 2nd class on Windows because MS have historically decided to >>>> not support UTF-8 properly on Windows, in an attempt of a futile >>>> vendor lock-in. >>>> >>> >>> Not sure that it was about lock in. At time Win32 was conceived, >>> UTF8 didn't exist. At time WinNt was shipped, it still was less >>> than a year old. Back then choosing UTF16 looked reasonable. >>> Up to ~15 years ago it was not clear that UTF8 not just won, but won >>> decisively, so siting on the fence, waiting for the outcome of the >>> battle and rooting for legacy was not totally unreasonable. For what >>> happened after that, you could not underestimated a factor of >>> laziness. >>>> Though this is changing now, I just ran a quick test and apparently >>>> calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with >>>> VS2022 on Windows 10 and I can pass UTF-8 filenames to >>>> narrow-string fopen() and they work properly. So there is progress! >>>> >>> >>> Can you try it with paths that are longer than 260 characters? Both >>> prefixed with "\\?\" and non-prefixed? >>> >> >> Non-prefixed, _mkdir() succeeds with a path of 247 unicode characters >> (406 bytes) and fails with 307 unicode chars (506 bytes). >> >> Prefixed with "\\?\" _mkdir() and fopen() appeared to work fine, >> tried up to 1275 unicode chars (2114 bytes), the largest path was: >> >> \\?\C:\Tmp\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää.txt >> >> >> >> >> Alas, the File Explorer left-hand tree failed to descend into so deep >> directory tree (double-click in right-hand pane worked, but left-hand >> tree was truncated at some point). When opened in Notepad or >> Notepad++, the too long paths were changed into tilde-style "short >> names", stripping the unicode chars: >> >> C:\tmp\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1.TXT >> >> >> > > > Prefixed Unicode is expected to work fine. Documentation is clear about > it. I was wondering about behavior of prefixed ASCII. I.e. fopen() with > default locale. With default locale it did not work on my machine (i.e. produced gibberish filenames instead of expected Unicode characters), e.g. jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää However, after setlocale(LC_ALL, ".UTF-8"); the narrow character _mkdir() and fopen() started to work fine. If you can set your Windows ACP to UTF-8, then the default locale ought to work as well I guess. I think last time I tried this the machine did not boot up any more. But this was many years ago.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-29 01:20 +0200 |
| Message-ID | <20241129012017.00002dcd@yahoo.com> |
| In reply to | #121066 |
On Fri, 29 Nov 2024 00:59:13 +0200 Paavo Helde <eesnimi@osa.pri.ee> wrote: > On 29.11.2024 00:21, Michael S wrote: > > On Thu, 28 Nov 2024 22:41:42 +0200 > > Paavo Helde <eesnimi@osa.pri.ee> wrote: > > > >> On 28.11.2024 15:19, Michael S wrote: > >>> On Thu, 28 Nov 2024 13:03:20 +0200 > >>> Paavo Helde <eesnimi@osa.pri.ee> wrote: > >>> > >>>> On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: > >>>>> On Wed, 27 Nov 2024 14:58:18 -0500 > >>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: > >>>>>> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: > >>>>>>> On Wed, 27 Nov 2024 17:24:05 +0200 > >>>>>>> Michael S <already5chosen@yahoo.com> wibbled: > >>>>>> .... > >>>>>>>> It works, but badly rather than fine. > >>>>>>>> Specifically, it works only with ASCII paths. Which, on > >>>>>>>> Windows, happen to be 2nd class. The biggest problem with > >>>>>>>> ASCII paths on Windows is > >>>>>>> > >>>>>>> How can ascii paths be 2nd class (whatever that means) given > >>>>>>> that ascii is a subset of utf-8? > >>>>>> > >>>>>> Because ascii is a subset of utf-8, any path name that > >>>>>> contains a character not in that subset cannot be represented, > >>>>>> which is what makes them 2nd class. > >>>>> > >>>>> Huh? Any ascii text is valid in UTF-8, that doesn't make ascii > >>>>> 2nd class. The only issue comes when some idiot tries to mix > >>>>> utf-8 with 8 bit ascii code pages. > >>>> > >>>> You are right, ASCII is not 2nd class because it is part of > >>>> UTF-8. It is 2nd class on Windows because MS have historically > >>>> decided to not support UTF-8 properly on Windows, in an attempt > >>>> of a futile vendor lock-in. > >>>> > >>> > >>> Not sure that it was about lock in. At time Win32 was conceived, > >>> UTF8 didn't exist. At time WinNt was shipped, it still was less > >>> than a year old. Back then choosing UTF16 looked reasonable. > >>> Up to ~15 years ago it was not clear that UTF8 not just won, but > >>> won decisively, so siting on the fence, waiting for the outcome > >>> of the battle and rooting for legacy was not totally > >>> unreasonable. For what happened after that, you could not > >>> underestimated a factor of laziness. > >>>> Though this is changing now, I just ran a quick test and > >>>> apparently calling setlocale(LC_ALL, "et_EE.UTF-8") now works > >>>> properly with VS2022 on Windows 10 and I can pass UTF-8 > >>>> filenames to narrow-string fopen() and they work properly. So > >>>> there is progress! > >>> > >>> Can you try it with paths that are longer than 260 characters? > >>> Both prefixed with "\\?\" and non-prefixed? > >>> > >> > >> Non-prefixed, _mkdir() succeeds with a path of 247 unicode > >> characters (406 bytes) and fails with 307 unicode chars (506 > >> bytes). > >> > >> Prefixed with "\\?\" _mkdir() and fopen() appeared to work fine, > >> tried up to 1275 unicode chars (2114 bytes), the largest path was: > >> > >> \\?\C:\Tmp\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää.txt > >> > >> > >> > >> > >> Alas, the File Explorer left-hand tree failed to descend into so > >> deep directory tree (double-click in right-hand pane worked, but > >> left-hand tree was truncated at some point). When opened in > >> Notepad or Notepad++, the too long paths were changed into > >> tilde-style "short names", stripping the unicode chars: > >> > >> C:\tmp\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1.TXT > >> > >> > >> > > > > > > Prefixed Unicode is expected to work fine. Documentation is clear > > about it. I was wondering about behavior of prefixed ASCII. I.e. > > fopen() with default locale. > > With default locale it did not work on my machine (i.e. produced > gibberish filenames instead of expected Unicode characters), e.g. > jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää > > However, after > > setlocale(LC_ALL, ".UTF-8"); > > the narrow character _mkdir() and fopen() started to work fine. > > If you can set your Windows ACP to UTF-8, then the default locale > ought to work as well I guess. I think last time I tried this the > machine did not boot up any more. But this was many years ago. > > > I did not have Japanese names in mind. I was asking about very long paths consisting of Latin characters. In my tests, which are written in C rather than in C++, they appear to work fine. So, it seems, my claim that ASCII is 2nd is either outdated or plain wrong. The OS (Win7) appears to work better than claimed by docs.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-11-28 17:18 -0500 |
| Message-ID | <viaq79$npcv$1@dont-email.me> |
| In reply to | #121048 |
On 11/28/24 03:26, Muttley@DastardlyHQ.org wrote: > On Wed, 27 Nov 2024 14:58:18 -0500 > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: ... >>> How can ascii paths be 2nd class (whatever that means) given that ascii >>> is a subset of utf-8? >> >> Because ascii is a subset of utf-8, any path name that contains a >> character not in that subset cannot be represented, which is what makes >> them 2nd class. > > Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd class True, what makes it 2nd class is UTF-8 text that is not valid ASCII text, exactly the opposite issue.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-11-27 19:01 +0200 |
| Message-ID | <vi7j8i$377p$1@dont-email.me> |
| In reply to | #121035 |
On 27.11.2024 15:54, Muttley@DastardlyHQ.org wrote: > On Wed, 27 Nov 2024 15:39:51 +0200 > Paavo Helde <eesnimi@osa.pri.ee> wibbled: >> On 27.11.2024 12:48, wij wrote: >>> >>> A clue for you: What should be in a 'portabe' program if ::fopen(..) failed? >> NULL >>> or nullptr? What about "if(::fopen(..)"? >> >> In a portable program one cannot just use fopen() as it does not work >> reliably with Unicode characters in Windows paths. One needs to use some >> kind of helper library for having portable code. In principle >> std::filesystem::path ought to work, but I have no experience with it. > > So how does file access work in plain C in Windows then? I'm pretty sure > fopen() works fine given its a core C API function. In C one can use _wfopen() or _wfopen_s() in Windows. As you can guess these are pretty non-portable. The libraries which provide their own file opening functions typically provide the wide char variants as well, specifially for supporting Windows. For example, libTIFF provides TIFFOpenW() and zlib provides gzopen_w(). In a better world MS should implement full support for the UTF-8 locale and deprecate all other locales, making all this wide char stuff unneeded. Not sure how far they are on this (IMO unevitable) path. In an ideal world they would have done that already 15 years ago.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2024-11-28 08:22 +0000 |
| Message-ID | <vi998b$fa66$1@dont-email.me> |
| In reply to | #121039 |
On Wed, 27 Nov 2024 19:01:06 +0200 Paavo Helde <eesnimi@osa.pri.ee> wibbled: >On 27.11.2024 15:54, Muttley@DastardlyHQ.org wrote: >> On Wed, 27 Nov 2024 15:39:51 +0200 >> Paavo Helde <eesnimi@osa.pri.ee> wibbled: >>> On 27.11.2024 12:48, wij wrote: >>>> >>>> A clue for you: What should be in a 'portabe' program if ::fopen(..) >failed? >>> NULL >>>> or nullptr? What about "if(::fopen(..)"? >>> >>> In a portable program one cannot just use fopen() as it does not work >>> reliably with Unicode characters in Windows paths. One needs to use some >>> kind of helper library for having portable code. In principle >>> std::filesystem::path ought to work, but I have no experience with it. >> >> So how does file access work in plain C in Windows then? I'm pretty sure >> fopen() works fine given its a core C API function. > >In C one can use _wfopen() or _wfopen_s() in Windows. As you can guess >these are pretty non-portable. > >The libraries which provide their own file opening functions typically >provide the wide char variants as well, specifially for supporting >Windows. For example, libTIFF provides TIFFOpenW() and zlib provides >gzopen_w(). > >In a better world MS should implement full support for the UTF-8 locale >and deprecate all other locales, making all this wide char stuff >unneeded. Not sure how far they are on this (IMO unevitable) path. In an >ideal world they would have done that already 15 years ago. What a mess. The unix approach whereby a filename is simply a sequence of bytes (except for \0 but I'm not 100% sure) seems a lot more sensible.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-27 11:00 -0800 |
| Message-ID | <qGidnVj_CYrh8dr6nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #121035 |
On 11/27/2024 05:54 AM, Muttley@DastardlyHQ.org wrote: > On Wed, 27 Nov 2024 15:39:51 +0200 > Paavo Helde <eesnimi@osa.pri.ee> wibbled: >> On 27.11.2024 12:48, wij wrote: >>> >>> A clue for you: What should be in a 'portabe' program if ::fopen(..) failed? >> NULL >>> or nullptr? What about "if(::fopen(..)"? >> >> In a portable program one cannot just use fopen() as it does not work >> reliably with Unicode characters in Windows paths. One needs to use some >> kind of helper library for having portable code. In principle >> std::filesystem::path ought to work, but I have no experience with it. > > So how does file access work in plain C in Windows then? I'm pretty sure > fopen() works fine given its a core C API function. > That's usually for a "portability layer", sort of an abstraction of a "hardware abstraction layer", a "system abstraction layer", what used to be ifdefs and what according to that M4 the macro-preprocessor is part of C standard and thus usually part of C/C++ toolchain, though that I'd be curious for C++ for a "portability layer", that things like object handles in Windows and file handles in posix, have also for usually enough a common sort of blocking and non-blocking I/O model, that gets callbacks involved, as with regards to things like "libuv" for example that of course have many, many implementations by many, many parties in terms of "portability layers" when system-programming. When I wrote portability layers for Windows and POSIX and a bit of, say, Tru64 or HPUX, these kinds of things, then also the "structured exception handling" vis-a-vis signals gets a bit involved and usually makes for a "C" layer vis-a-vis "C++", if because the system libraries their symbols for the loader and linker are according to the conventions of course, that anyways a "portability layer" is very, very usual a thing to move all the "ifdefs" according to the OS in the layer and coding to the layer, which may be quite concrete in terms of what results being typedef'd handles as it were, in terms of that being direct. The FindFirstFile and this kind of thing, CreateFile, vis-a-vis opendir and open and this kind of thing, and the flags, have that something like Java API has a really great shape of its abstraction of these kinds of things, as with regards to Windows and UNC's and their sort-a like being URL's, URI's, URN's, .... It works pretty much the same is what it does, yet, a bit differently.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-11-27 14:57 -0500 |
| Message-ID | <vi7tji$4ur3$2@dont-email.me> |
| In reply to | #121033 |
On 11/27/24 08:39, Paavo Helde wrote: ... > About null pointers: in C++ it is spelled `nullptr`. No, in C++, using nullptr is one way to get a null pointer. It is not, however, the only way: "A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to zero or an rvalue of type std::nullptr_t. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type..." (4.10p1). Note that nullptr is an rvalue of type std::nullptr_t, but other things can also have that type. Also, null pointers can be created by conversion from null pointer constants, but they can also be generated by other means.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2024-11-27 13:52 +0000 |
| Message-ID | <vi787e$1coj$1@dont-email.me> |
| In reply to | #121031 |
On Wed, 27 Nov 2024 18:48:13 +0800 wij <wyniijj5@gmail.com> wibbled: >On Wed, 2024-11-27 at 08:26 +0000, Muttley@DastartdlyHQ.org wrote: >> On Wed, 27 Nov 2024 16:23:55 +0800 >> wij <wyniijj5@gmail.com> boring babbled: >> > On Tue, 2024-11-26 at 12:21 +0800, wij wrote: >> > > looks bad, but it works fine. Any way, inventing nullptr for such rar= >e? c=3D >> > ase >> > > is IOM overkill. >> >=20 >> > I think now, inventing nullptr is a practical step of evolution. So, in= > the >> > future, expansion of NULL might be nullptr. ... NULL will still be vali= >d fo=3D >> > r=3DC2=3DA0 >> > a long time, both in C and C++. >>=20 >> Stop replying to your own nonsense with yet more nonsense. No one cares. > >It was a correction of my previous post. Not every post is for you. Not sure yours are for anyone except yourself. >If you feel sth have to utter, utter sth on topic. We know you are not ther= >e, but >we won't laught. You could translate that into comprehensible english? >A clue for you: What should be in a 'portabe' program if ::fopen(..) failed= >? NULL=C2=A0 >or nullptr? What about "if(::fopen(..)"? Any chance you could stop your newsreader randomly using QP encoding for 7 bit ascii characters?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-11-27 14:54 -0500 |
| Message-ID | <vi7tco$4ur3$1@dont-email.me> |
| In reply to | #121034 |
On 11/27/24 08:52, Muttley@DastardlyHQ.org wrote: > On Wed, 27 Nov 2024 18:48:13 +0800 > wij <wyniijj5@gmail.com> wibbled: ... >> If you feel sth have to utter, utter sth on topic. We know you are not ther= >> e, but >> we won't laught. > > You could translate that into comprehensible english? Of course he can't - he's wij. Comprehensibility is not an available option for him.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-28 15:27 +0200 |
| Message-ID | <20241128152750.000032de@yahoo.com> |
| In reply to | #121042 |
On Wed, 27 Nov 2024 14:54:00 -0500 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 11/27/24 08:52, Muttley@DastardlyHQ.org wrote: > > On Wed, 27 Nov 2024 18:48:13 +0800 > > wij <wyniijj5@gmail.com> wibbled: > ... > >> If you feel sth have to utter, utter sth on topic. We know you are > >> not ther= e, but > >> we won't laught. > > > > You could translate that into comprehensible english? > > Of course he can't - he's wij. Comprehensibility is not an available > option for him. > Do you realize that your reply can be interpreted as that you sympathies Muttley's rude attempt of policing wij ? I hope that it was not your intention.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-27 15:30 +0200 |
| Message-ID | <20241127153058.00005be4@yahoo.com> |
| In reply to | #121030 |
On Wed, 27 Nov 2024 08:26:12 -0000 (UTC) Muttley@DastartdlyHQ.org wrote: > On Wed, 27 Nov 2024 16:23:55 +0800 > wij <wyniijj5@gmail.com> boring babbled: > >On Tue, 2024-11-26 at 12:21 +0800, wij wrote: > >> looks bad, but it works fine. Any way, inventing nullptr for such > >> rare? c= > >ase > >> is IOM overkill. > > > >I think now, inventing nullptr is a practical step of evolution. So, > >in the future, expansion of NULL might be nullptr. ... NULL will > >still be valid fo= r=C2=A0 > >a long time, both in C and C++. > > Stop replying to your own nonsense with yet more nonsense. No one > cares. > Nothing particularly wrong in replying to own posts, nonsense or not. Esp. so when the thread was started by yourself. What *is* wrong and annoying is starting lots of nonsense short threads.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-28 18:32 -0800 |
| Message-ID | <87r06usrbm.fsf@nosuchdomain.example.com> |
| In reply to | #121021 |
wij <wyniijj5@gmail.com> writes:
> On Mon, 2024-11-25 at 14:03 -0800, Keith Thompson wrote:
[...]
>> nullptr exists in C++ (I don't remember when it was introduced) and in C
>> starting with C23.
>
> Thanks, I didn't know that
>
>> It is, in my opinion, what should have been provided
>> in both languages instead of the NULL macro.
>>
> My question would be: why not make NULL a 'reserved' word, instead of macro?
NULL and nullptr have subtly different semantics. Making NULL a keyword
could break existing code. (And an all-caps keyword would be ugly.)
[...]
> So far, I can still avoid using variadic functions. I use overload. Implement
> looks bad, but it works fine. Any way, inventing nullptr for such rare? case
> is IOM overkill.
nullptr was introduced in C++11. Your misgivings are a bit late.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-25 14:00 -0800 |
| Message-ID | <87mshnkm8q.fsf@nosuchdomain.example.com> |
| In reply to | #120982 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> In my opinion, the main reason for NULL is that it lets the programmer
> explicitly state that it's a null pointer constant and not just zero.
> (But NULL can still be of type int.) I find nullptr (in C++ and C23) an
> improvement over NULL.
To summarize, the purpose of using NULL rather than 0 is to communicate
information to the human reader, not to the compiler. There are
contexts where you need to write `(void*)NULL` rather than just `NULL`.
printf("%p\n", NULL); // UB in C++, possible UB in C
printf("%p\n", (void*)NULL); // OK
(There's probably more to say about using nullptr in this context, but
I'll leave that to others.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-25 14:15 -0800 |
| Message-ID | <vi2sup$31jrd$2@dont-email.me> |
| In reply to | #121017 |
On 11/25/2024 2:00 PM, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>> In my opinion, the main reason for NULL is that it lets the programmer
>> explicitly state that it's a null pointer constant and not just zero.
>> (But NULL can still be of type int.) I find nullptr (in C++ and C23) an
>> improvement over NULL.
>
> To summarize, the purpose of using NULL rather than 0 is to communicate
> information to the human reader, not to the compiler. There are
> contexts where you need to write `(void*)NULL` rather than just `NULL`.
>
> printf("%p\n", NULL); // UB in C++, possible UB in C
> printf("%p\n", (void*)NULL); // OK
>
> (There's probably more to say about using nullptr in this context, but
> I'll leave that to others.)
>
I think I remember way back when casting to (void*) for %p is necessary.
Think of function pointers? Shit its been a while. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-12-01 21:00 -0800 |
| Message-ID | <864j3mof17.fsf@linuxsc.com> |
| In reply to | #121017 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] > >> In my opinion, the main reason for NULL is that it lets the >> programmer explicitly state that it's a null pointer constant and >> not just zero. (But NULL can still be of type int.) I find >> nullptr (in C++ and C23) an improvement over NULL. > > To summarize, the purpose of using NULL rather than 0 is to > communicate information to the human reader, [...] That is one purpose for using NULL, but it doesn't have to be the only one.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-11-26 04:26 -0800 |
| Message-ID | <86h67uqize.fsf@linuxsc.com> |
| In reply to | #120976 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] The main reason for NULL is that some implementations > thought it would be better for type safety to use (void*)0. The problem with that theory is NULL predates both C++ and also any introduction of void or the void* type.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-11-20 23:20 -0500 |
| Message-ID | <vhmcdj$ggpc$1@dont-email.me> |
| In reply to | #120951 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/20/2024 2:11 PM, Scott Lurndal wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> On 11/19/2024 11:22 PM, Paavo Helde wrote: >>>> On 20.11.2024 05:02, wij wrote: ... >>> EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? >> >> >> Not on any POSIX system. EXIT_SUCCESS must be zero. EXIT_FAILURE >> must be between 1 and 125 inclusive. >> >> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/stdlib.h.html >> > >What about the strict C std, posix aside for a moment? The only requirements are that EXIT_FAILURE and EXIT_SUCCESS must "expand to integer constant expressions that can be used as the argument to the exit function to return unsuccessful or successful termination status, respectively, to the host environment;" (7.24p4) It's completely up to the implementation which expressions are used, and there's no requirement that there be a direct connection between the value passed to exit() and the numeric value received by the host environment. In fact, there's no requirement that the status be in the form of an integer value. A value of 0 passed to exit() must also result in returning a successful termination status to the host environment. EXIT_SUCCESS is not required to expand to an integer constant expression with a value of 0, nor is it prohibited from doing so.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-20 17:32 -0800 |
| Message-ID | <6P2cnW3IY5MQEKP6nZ2dnZfqn_SdnZ2d@giganews.com> |
| In reply to | #120950 |
On 11/20/2024 02:11 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 11/19/2024 11:22 PM, Paavo Helde wrote: >>> On 20.11.2024 05:02, wij wrote: >>>> EXIT_SUCCESS/EXIT_FAILURE are for communication between different >>>> programs. >>>> But, is it necessary? E.g. can it be put into shell script? >>>> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >>>> programs for some reason, but generally, exit code of program is a >>>> numerical >>>> value. Why EXIT_SUCCESS? >>>> >>>> >>> >>> EXIT_SUCCESS is an attempt to provide an abstraction which was attempted >>> to cover more different platforms than POSIX style exit codes. The idea >>> was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >>> the program is compiled to run on some Unix, on some weird mainframe >>> with weird exit code values, or in some free-standing implementation >>> where there is no OS, not to speak about shell scripts. >>> >>> Even on Linux or Windows, note that the exit code numeric values >>> contradict the conventions of C and C++ where 1 is normally converted to >>> true and 0 to false. So to reduce confusion it might be a good idea to >>> use the macros even here. Note that nowadays there are many programmers >>> (esp. on Windows) who have no idea about program exit code conventions >>> or shell scripts. >>> >>> >> >> EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? > > > Not on any POSIX system. EXIT_SUCCESS must be zero. EXIT_FAILURE > must be between 1 and 125 inclusive. > > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/stdlib.h.html > Thanks that's interesting as sometimes one sees 255. It's great that the return code may be structured, yet because anything non-zero might be lost usually there's only "= EXIT_SUCCESS" and "!= EXIT_SUCCESS", or as with regards to shell syntax where expressions in shell commands have that conditionally "command1 && command2" executes command2 iff command1 results EXIT_SUCCESS, which equals 0 most everywhere, though that being the opposite of a usual arithmetic expression where true = non-zero and false = zero, as with regards to the error case being 1, or 1-125, or 255, or INT_MAX, or 0xFFFFFFFF. Anyways an error of whatever value might get translated to "err..." for example 1 or 255, so, it's usual to test only that "= EXIT_SUCCESS" or "= 0" the code, while it's usually considered clear that "exit 0" is "exit EXIT_SUCCESS" while "exit 1" is any "not EXIT_SUCCESS". As a structured return code otherwise the semantics of main according to POSIX, structured return codes is a great idea unfortunately very particular to usage, and as well the runtime and as well any interpreter. "Portable-subset-of-POSIX-ly a process-model-ing", .... This being not relevant to C++ largely and rather the runtime I'll now obligatorily Ctrl-w myself a bunch of times, yet the constants in the headers are for returning them from main, only, pretty much, that being defined.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2024-11-20 22:56 -0800 |
| Message-ID | <vhmljm$hln3$1@redfloyd.dont-email.me> |
| In reply to | #120955 |
On 11/20/2024 5:32 PM, Ross Finlayson wrote: > Thanks that's interesting as sometimes one sees 255. > I believe that in POSIX, exit codes between 128 to 128 + NSIG inclusive indicate the termination was caused by a signal.
[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