f



To 'C' or not to 'C' ... now what the hell to I do?

From the WTF department!  (WTF: What the fuck!)

I have an application that is written in 'C'.  It works flawlessly under
OpenVMS Alpha V7.3-2 and V8.2.  However, I just ran this same executable
on V8.3.  It's a mess.  Because it is the same executable as run on the 
other VMS versions, I'd conclude that there's something SERIOUSLY horked
in the C RTL on V8.3.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/17/2008 10:32:44 PM
comp.os.vms 21904 articles. 1 followers. Post Follow

76 Replies
1209 Views

Similar Articles

[PageSpeed] 27

In article <gIQjj.1370$eT.982@newsfe12.lga>, VAXman-  @SendSpamHere.ORG 
wrote:

> From the WTF department!  (WTF: What the fuck!)
> 
> I have an application that is written in 'C'.  It works flawlessly under
> OpenVMS Alpha V7.3-2 and V8.2.  However, I just ran this same executable
> on V8.3.  It's a mess.  Because it is the same executable as run on the 
> other VMS versions, I'd conclude that there's something SERIOUSLY horked
> in the C RTL on V8.3.

For either of your two questions (WTF? and "now what?") some 
description of the mess might increase the accuracy of guesses for 
people attempting to answer.  If the CRTL is involved in your problems 
(and there's no evidence of that here as yet), the first thing I'd do 
is check and compare feature settings between the two systems:

$ show logical DECC$*

Other system differences only tangentially related (or even completely 
unrelated) to VMS version could play a role in conjunction with the 
CRTL.  If file operations are part of the mix, do the disks you are 
operating on have the same volume formats?  If ODS-5 is involved, are 
access dates and/or hard links enabled on the disk(s) in question?

But perhaps file access is not even involved, so what exactly is 
involved?

-- 
Posted via a free Usenet account from http://www.teranews.com

0
craigberry (308)
1/17/2008 11:35:56 PM
VAXman- @SendSpamHere.ORG wrote:
> I have an application that is written in 'C'.  It works flawlessly under
> OpenVMS Alpha V7.3-2 and V8.2.  However, I just ran this same executable
> on V8.3.  It's a mess.  Because it is the same executable as run on the 
> other VMS versions, I'd conclude that there's something SERIOUSLY horked
> in the C RTL on V8.3.

Can you better describe the "mess" ? There are a bunch of logicals that
affect C programs, how they access files etc. Perhaps those logicals are
not the same on your 8.3 system.
0
1/17/2008 11:38:58 PM
VAXman- @SendSpamHere.ORG wrote:
> From the WTF department!  (WTF: What the fuck!)
> 
> I have an application that is written in 'C'.  It works flawlessly under
> OpenVMS Alpha V7.3-2 and V8.2.  However, I just ran this same executable
> on V8.3.  It's a mess.  Because it is the same executable as run on the 
> other VMS versions, I'd conclude that there's something SERIOUSLY horked
> in the C RTL on V8.3.

Not necessarily.

A common problem in C is to use the address of a local stack variable in 
a context that survives past the execution of the routine that defined 
the variable.  For example, using local stack based IOSB with a $QIO 
that completes after the current routine returns.

The suspect stack locations may or may not be trashed or accessed by 
subsequent calls.  If not, you lucked out and the program runs.

If an RTL change is made that changes some stack offsets so the problem 
location is now used, the program may fail.  Note that there is nothing 
problematic about the changes made to the RTL.  They just had the side 
effect of exposing the original programming error.

Finding these problems can be "interesting".  Sometimes compiling both 
optimized and nonoptimized and testing may help to find the problem. 
Sometimes stepping through the code with the debugger helps to trigger 
the problem.

Good luck!

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris@applied-synergy.com
   Fax: 817-237-3074
0
Chris
1/18/2008 12:04:59 AM
On Jan 17, 5:32=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> From the WTF department! =A0(WTF: What the fuck!)

http://thedailywtf.com/Default.aspx


>
> I have an application that is written in 'C'. =A0It works flawlessly under=

> OpenVMS Alpha V7.3-2 and V8.2. =A0

I beg to differ. It APPEARS to work flawlesly,
but that was pure bad luck.

> However, I just ran this same executable on V8.3. =A0It's a mess. =A0

Now there's a fine concise error description for us chew on!
What C-RTL version?
Can you try that C-RTL on 8.2
Can you try a C-CRTL borrowed from 8.2 on 8.3 using some logical
names?

Speaking of logical names.... the C-RTL is willing to change behaviour
drastically based on logical names. Was there an environmental change,
different DECC$* logicals between teh 8.2 and 8.3 testbed?

> Because it is the same executable as run on the
> other VMS versions, I'd conclude that there's something SERIOUSLY horked i=
n the C RTL on V8.3.

65,536 other happy programs beg to differ.

Good luck!
Hein.
0
1/18/2008 12:30:36 AM
On Jan 17, 5:32 pm, VAXman-  @SendSpamHere.ORG wrote:
> From the WTF department!  (WTF: What the fuck!)
>
> I have an application that is written in 'C'.  It works flawlessly under
> OpenVMS Alpha V7.3-2 and V8.2.  However, I just ran this same executable
> on V8.3.  It's a mess.  Because it is the same executable as run on the
> other VMS versions, I'd conclude that there's something SERIOUSLY horked
> in the C RTL on V8.3.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
>
>   "Well my son, life is like a beanstalk, isn't it?"
>
> http://tmesis.com/drat.html

VAXman,

I would have to agree with Hein, the behavior is consistent with
"illegal but appears to function correctly" code.

This can be anything from a reserved, but previously unused parameter
being mis-set, to a change in the usage of the stack by underlying
routines. I first started using this phrase when a problem occurred
many years ago when switching from RSX-11M 3.0 to 3.1. In 3.0, any
terminal driver QIO was implicitly a QIOW, in 3.1 that
"feature" (which was an artifact of the implementation, never
intended) was corrected. This uncovered a latent bug caused by a
typographical error (QIO instead of the intended QIOW).

The only solution that I have ever found for these is a careful review
of the sources, and possibly debugging code to somewhat localize when
things go off of the rails.

- Bob Gezelter, http://www.rlgsc.com
0
gezelter (551)
1/18/2008 11:42:26 AM
On Jan 18, 5:42 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
> The only solution that I have ever found for these is a careful review
> of the sources, and possibly debugging code to somewhat localize when
> things go off of the rails.
>
> - Bob Gezelter,http://www.rlgsc.com

A good way to squeeze them out is to LINT the source code, or at least
compile with the switches set to flag ALL uninitialized variables.
(Lint used to be better because it would flag return values that were
out of scope).

0
yyyc186 (230)
1/18/2008 2:09:09 PM
Hein RMS van den Heuvel wrote:
> On Jan 17, 5:32 pm, VAXman-  @SendSpamHere.ORG wrote:
>> From the WTF department!  (WTF: What the fuck!)
> 
> http://thedailywtf.com/Default.aspx
> 
> 
>> I have an application that is written in 'C'.  It works flawlessly under
>> OpenVMS Alpha V7.3-2 and V8.2.  
> 
> I beg to differ. It APPEARS to work flawlesly,
> but that was pure bad luck.
> 
>> However, I just ran this same executable on V8.3.  It's a mess.  
> 
> Now there's a fine concise error description for us chew on!
> What C-RTL version?
> Can you try that C-RTL on 8.2
> Can you try a C-CRTL borrowed from 8.2 on 8.3 using some logical
> names?
> 
> Speaking of logical names.... the C-RTL is willing to change behaviour
> drastically based on logical names. Was there an environmental change,
> different DECC$* logicals between teh 8.2 and 8.3 testbed?

One thing to watch out for is layered and third party products that 
incorrectly set DECC$* logicals in the system table.

Other logical names incorrectly set in the system table that will break 
C programs are:

TMP
BIN
SYS$POSIX_ROOT

One other thing that could cause a failure is that between 8.2 and 8.3, 
more X/Open "UNIX" API routines where implemented.

Some of these entry points in the C library were present, but returned 
an error, and set errno to ENOSYS when called on 8.2.

So a C program could change functionality if it was testing for those 
features and only using them if the C library admitted to them working.

One of these things is symbolic links.  In Perl when 5.10 was being 
developed, it was discovered that the unlink()/remove()/delete() 
routines delete the target of the symbolic link instead of the symbolic 
link.  This is incorrect behavior.

This was previously been reported on this newsgroup/mailing list.

I do not know if a patch is available for the C library to fix this.  In 
perl, special case code was needed to be wrapped around the unlink() 
call to call the RMS system service instead.  The RMS system service, as 
  does DCL handles the deletion of symbolic links correctly.

-John
wb8tyw@qsl.network
Personal Opinion Only
0
wb8tyw (629)
1/18/2008 2:46:16 PM
In article <f3eca386-8afa-447a-aa40-f80344c4edb7@s8g2000prg.googlegroups.com>, yyyc186 <yyyc186@hughes.net> writes:
>
>
>On Jan 18, 5:42 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>> The only solution that I have ever found for these is a careful review
>> of the sources, and possibly debugging code to somewhat localize when
>> things go off of the rails.
>>
>> - Bob Gezelter,http://www.rlgsc.com
>
>A good way to squeeze them out is to LINT the source code, or at least
>compile with the switches set to flag ALL uninitialized variables.
>(Lint used to be better because it would flag return values that were
>out of scope).

I tried compiling with /CHECK, enabling all of the checks (bounds, the
unitialized variables and the pointer checks).  Nothing.

This code doesn't use many C RTL fucntions.  ATOI, printf and sprintf
come file functions to read an initialization file at startup (which
is appears to be doing correctly) STRLEN, STRCAT, STRCHR, STRCPY and
the N equivalents and the TOUPPER.

Anyway, the output of this app is what is horked.  I'll keep plugging
away looking.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/18/2008 4:58:46 PM
In article <gIQjj.1370$eT.982@newsfe12.lga>, VAXman-  @SendSpamHere.ORG writes:
>I have an application that is written in 'C'.  It works flawlessly under
>OpenVMS Alpha V7.3-2 and V8.2.  However, I just ran this same executable
>on V8.3.  It's a mess.  Because it is the same executable as run on the 
>other VMS versions, I'd conclude that there's something SERIOUSLY horked
>in the C RTL on V8.3.

I don't think so (if you don't count the new symbolic link support/problems),
but you may try the VMS83A_ACRTL ECO (currently V4) and see what changes:

  ftp://ftp.itrc.hp.com/openvms_patches/alpha/V8.3/VMS83A_ACRTL-V0400.ZIPEXE
  ftp://ftp.itrc.hp.com/openvms_patches/alpha/V8.3/VMS83A_ACRTL-V0400.txt

-- 
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail  peter@langstoeger.at
A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist
0
peter
1/18/2008 7:29:51 PM
VAXman- wrote:
> yyyc186 <yyyc186@hughes.net> writes:
>> Bob Gezelter <gezel...@rlgsc.com> wrote:
>>> The only solution that I have ever found for these is a careful review
>>> of the sources, and possibly debugging code to somewhat localize when
>>> things go off of the rails.
>>> - Bob Gezelter,http://www.rlgsc.com
>>
>>A good way to squeeze them out is to LINT the source code, or at least
>>compile with the switches set to flag ALL uninitialized variables.
>>(Lint used to be better because it would flag return values that were
>>out of scope).
> 
> I tried compiling with /CHECK, enabling all of the checks (bounds, the
> unitialized variables and the pointer checks).  Nothing.
>    This code doesn't use many C RTL fucntions.  ATOI, printf and sprintf
> come file functions to read an initialization file at startup (which
> is appears to be doing correctly) STRLEN, STRCAT, STRCHR, STRCPY and
> the N equivalents and the TOUPPER.
>    Anyway, the output of this app is what is horked.  I'll keep plugging
> away looking.

Sounds like some straightforward ansi-standard C program.
You use descrip.h, ssdef.h, or any other vms stuff?
If not, and if it is straight ansi C, try downloading
to a linux box, or any other handy environment that'll
compile and run standard C for you.  You may get lucky
and watch it blow up, rather than run to completion with
the wrong results.  That should be a lot easier to debug.
(And try compiling with the -O3 -pedantic -Wall switches.)
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )
0
johnf (11)
1/18/2008 7:53:51 PM
On Jan 18, 11:58=A0am, VAXman-  @SendSpamHere.ORG wrote:
> In article <f3eca386-8afa-447a-aa40-f80344c4e...@s8g2000prg.googlegroups.c=
om>, yyyc186 <yyyc...@hughes.net> writes:

> This code doesn't use many C RTL fucntions. =A0ATOI, printf and sprintf
> come file functions to read an initialization file at startup (which
> is appears to be doing correctly) STRLEN, STRCAT, STRCHR, STRCPY and the N=
 equivalents and the TOUPPER.

Basic stuff. If any of that is broken, the world would fall over. Too
big a bug.


> Anyway, the output of this app is what is horked. =A0

Boy you are a hard person to support.
Gotta really poke you to egt half useful descriptions :-).
I hope your own customers treat you better!

May we interpret this as the screen formatting being incorrect, but
the data correct, or the other way around?

In the first case, how about sime terminal settings? Try with a
terminal emulator in dta-scope mode?

In the second case, where is the data coming from? File? Run with SET
WATCH  FILE/CLA=3DMAJOR and see if the righ files are touched?

Hein.
0
1/18/2008 8:15:53 PM
VAXman- @SendSpamHere.ORG wrote:

> Anyway, the output of this app is what is horked.  I'll keep plugging
> away looking.

You really need to provide a better description of the problem. Is it
gibberish characters ? Are the numbers wrongly calculated ?

Is the output to terminal or to a file ?
0
1/18/2008 8:46:49 PM
In article <4791108f$0$15795$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
>
>VAXman- @SendSpamHere.ORG wrote:
>
>> Anyway, the output of this app is what is horked.  I'll keep plugging
>> away looking.
>
>You really need to provide a better description of the problem. Is it
>gibberish characters ? Are the numbers wrongly calculated ?
>
>Is the output to terminal or to a file ?

I've been working on this all day.  Sorry for not reporting back.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/18/2008 9:36:10 PM
In article 
<c03f4b2a-f185-480c-945c-0392d86b4b4f@s13g2000prd.googlegroups.com>,
 Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> wrote:

> On Jan 18, 11:58�am, VAXman-  @SendSpamHere.ORG wrote:
> > This code doesn't use many C RTL fucntions. �

And that's what led you to suspect the CRTL first?

> > ATOI, printf and sprintf
> > come file functions to read an initialization file at startup (which
> > is appears to be doing correctly) STRLEN, STRCAT, STRCHR, STRCPY and the N 
> > equivalents and the TOUPPER.
> 
> Basic stuff. If any of that is broken, the world would fall over. Too
> big a bug.

True, but check the locale settings for any differences between the two 
systems.

-- 
Posted via a free Usenet account from http://www.teranews.com

0
craigberry (308)
1/19/2008 2:24:35 AM
In article <craigberry-FFA012.20243518012008@free.teranews.com>, "Craig A. Berry" <craigberry@mac.com.spamfooler> writes:
>
>
>In article 
><c03f4b2a-f185-480c-945c-0392d86b4b4f@s13g2000prd.googlegroups.com>,
> Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> wrote:
>
>> On Jan 18, 11:58�am, VAXman-  @SendSpamHere.ORG wrote:
>> > This code doesn't use many C RTL fucntions. �
>
>And that's what led you to suspect the CRTL first?

No.  But swapping with V8.2's DECC$SHR does correct the problem.

$ DEFINE DECC$SHR AS200$DKA200:[VMS$COMMON.SYSLIB]DECC$SHR.EXE;1

...and then running the application!

I verified that the V8.2 DECC$SHR was being used too!  On this particular
system, V8.3 is on DKA300: and V8.2 is on DKA200:  Take a look at channel
100 below.


Process index: 0083   Name: _LTA5032:         Extended PID: 21400283
--------------------------------------------------------------------

Channel    CCB     Window     Status    Device/file accessed
-------    ---     ------     ------    --------------------
  00D0  7FF7C180  81F703C0              ALPHA$DKA300:[VMS$COMMON.SYSLIB]DEC$FORRTL.EXE;1 (section file)
  00E0  7FF7C1A0  81F6CA80              ALPHA$DKA300:[VMS$COMMON.SYSLIB]NCSSHR.EXE;1 (section file)
  00F0  7FF7C1C0  81F6B500              ALPHA$DKA300:[VMS$COMMON.SYSLIB]CMA$TIS_SHR.EXE;1 (section file)
  0100  7FF7C1E0  821D7DC0              ALPHA$DKA200:[VMS$COMMON.SYSLIB]DECC$SHR.EXE;1 <<<======<<<<<
  0110  7FF7C200  81F6CC80              ALPHA$DKA300:[VMS$COMMON.SYSLIB]DPML$SHR.EXE;1 (section file)
  0120  7FF7C220  81F65DC0              ALPHA$DKA300:[VMS$COMMON.SYSLIB]SYS$SSISHR.EXE;1 (section file)
  0130  7FF7C240  81F69E00              ALPHA$DKA300:[VMS$COMMON.SYSLIB]DEBUG.EXE;1 (section file)
  0140  7FF7C260  81F7C8C0              ALPHA$DKA300:[VMS$COMMON.SYSMSG]SHRIMGMSG.EXE;1 (section file)
  0150  7FF7C280  81F5A840              ALPHA$DKA300:[VMS$COMMON.SYSMSG]SORTMSG.EXE;1
  0160  7FF7C2A0  81F7B940              ALPHA$DKA300:[VMS$COMMON.SYSMSG]DECC$MSG.EXE;1 (section file)
  0170  7FF7C2C0  821AFEC0              ALPHA$DKA300:[VMS$COMMON.SYSMSG]DBGTBKMSG.EXE;1
  0190  7FF7C300  00000000              MBA376:

  Total number of open channels : 24.
SDA>

BTW, this is the complete list of RTLs from the .MAP file.

DECC$ATOI
DECC$FCLOSE
DECC$FGETC
DECC$FOPEN
DECC$FREE
DECC$FSEEK
DECC$GFPRINTF
DECC$GPRINTF
DECC$GSPRINTF
DECC$GSSCANF
DECC$MALLOC
DECC$MEMCPY
DECC$PUTS
DECC$SLEEP
DECC$STRCAT
DECC$STRCHR
DECC$STRCHR
DECC$STRCPY
DECC$STRLEN
DECC$STRNCAT
DECC$STRNCMP
DECC$STRNCPY
DECC$TOUPPER


I am busy trying to find the culprit in the file.  I know that somewhere,
one byte is being written incorrectly.  I've been trying to isolate it by
using a watchpoint.  It's an inordinately slow process because there is a
very large regression suite to run before the error occurs.  Once there,
I can delve in deeper.


>> > ATOI, printf and sprintf
>> > come file functions to read an initialization file at startup (which
>> > is appears to be doing correctly) STRLEN, STRCAT, STRCHR, STRCPY and the N 
>> > equivalents and the TOUPPER.
>> 
>> Basic stuff. If any of that is broken, the world would fall over. Too
>> big a bug.
>
>True, but check the locale settings for any differences between the two 
>systems.

There are NO DECC logicals defined making any special changes to the 
behavior.

Running this:

#include <unixlib.h>
main () { decc$feature_show_all(); }

shows:

** C RTL Feature settings
 ---------- C RTL Feature  Name ----------   Cur    Def    Min    Max Ini
 DECC$FIXED_LENGTH_SEEK_TO_EOF                 0      0      0      1  -1
 DECC$POSIX_SEEK_STREAM_FILE                   0      0      0      1  -1
 DECC$SELECT_IGNORES_INVALID_FD                0      0      0      1  -1
 DECC$STRTOL_ERANGE                            0      0      0      1  -1
 DECC$VALIDATE_SIGNAL_IN_KILL                  0      0      0      1  -1
 DECC$WRITE_SHORT_RECORDS                      0      0      0      1  -1
 DECC$ARGV_PARSE_STYLE                         0      0      0      1  -1
 DECC$EFS_CASE_PRESERVE                        0      0      0      2  -1
 DECC$PIPE_BUFFER_SIZE                       512    512    512  65024  -1
 DECC$PIPE_BUFFER_QUOTA                       -1     -1    512 2147483647  -1
 DECC$STDIO_CTX_EOL                            0      0      0      1  -1
 DECC$USE_RAB64                                0      0      0      1  -1
 DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION       0      0      0      1  -1
 DECC$EFS_CHARSET                              0      0      0      1  -1
 DECC$FILENAME_UNIX_NO_VERSION                 0      0      0      1  -1
 DECC$FILENAME_UNIX_REPORT                     0      0      0      1  -1
 DECC$READDIR_DROPDOTNOTYPE                    0      0      0      1  -1
 DECC$RENAME_NO_INHERIT                        0      0      0      1  -1
 DECC$GLOB_UNIX_STYLE                          0      0      0      1  -1
 DECC$EFS_FILE_TIMESTAMPS                      0      0      0      1  -1
 DECC$EXEC_FILEATTR_INHERITANCE                0      0      0      2  -1
 DECC$FILE_OWNER_UNIX                          0      0      0      1  -1
 DECC$FILE_PERMISSION_UNIX                     0      0      0      1  -1
 DECC$FILE_SHARING                             0      0      0      1  -1
 DECC$FILENAME_UNIX_ONLY                       0      0      0      2  -1
 DECC$POSIX_STYLE_UID                          0      0      0      1  -1
 DECC$USE_JPI$_CREATOR                         0      0      0      1  -1
 DECC$DETACHED_CHILD_PROCESS                   0      0      0      1  -1
 DECC$ALLOW_REMOVE_OPEN_FILES                  0      0      0      1  -1
 DECC$ENABLE_GETENV_CACHE                      0      0      0      1  -1
 DECC$ENABLE_TO_VMS_LOGNAME_CACHE              0      0     -1   3600  -1
 DECC$EFS_NO_DOTS_IN_DIRNAME                   0      0      0      1  -1
 DECC$TZ_CACHE_SIZE                            2      2      0    500  -1
 DECC$UMASK                                    0      0      0    511  -1
 DECC$UNIX_LEVEL                               0      0      0    100  -1
 DECC$DEFAULT_LRL                          32767  32767      0  32767  -1
 DECC$DEFAULT_UDF_RECORD                       0      0      0      1  -1
 DECC$DISABLE_POSIX_ROOT                       1      0      0      1  -1
 DECC$EFS_CASE_SPECIAL                         0      0      0      1  -1
 DECC$LOCALE_CACHE_SIZE                        0      0      0 357913941  -1
 DECC$MAILBOX_CTX_STM                          0      0      0      1   0
 DECC$READDIR_KEEPDOTDIR                       0      0      0      1  -1
 DECC$THREAD_DATA_AST_SAFE                     0      0      0      1  -1
 DECC$V62_RECORD_GENERATION                    0      0      0      1  -1
 DECC$XPG4_STRPTIME                            0      0      0      1  -1
 DECC$UNIX_PATH_BEFORE_LOGNAME                 0      0      0      1  -1
 DECC$TRACE                                    0      0      0      3  -1
 DECC$FD_LOCKING                               0      0      0      1  -1
 DECC$ALLOW_UNPRIVILEGED_NICE                  0      0      0      1  -1
 DECC$NO_ROOTED_SEARCH_LISTS                   0      0      0      1  -1
 DECC$ACL_ACCESS_CHECK                         0      0      0      1  -1
 DECC$GLOB_VMS_STYLE                           0      0      0      1  -1
 DECC$WLS                                      0      0      0      1  -1
 DECC$RENAME_ALLOW_DIR                         0      0      0      1  -1
 DECC$MPROTECT_REQUIRES_MMAP                   0      0      0      1  -1
 DECC$POPEN_NO_CRLF_REC_ATTR                   0      0      0      1  -1
 DECC$FP_LOCKING_DISABLE                       0      0      0      1  -1
 DECC$STREAM_PIPE                              0      0      0      1  -1
 DECC$SYMLINKS                                 1      1      0      1  -1
 DECC$COMMON_STDERR_STDOUT                     0      0      0      1  -1
 DECC$POSIX_COMPLIANT_PATHNAMES                0      0      0      4  -1
 DECC$POSIX_COMPLIANT_VERSIONS                 0      0      0      1  -1
 DECC$MUNMAP_DELETE                            0      0      0      1  -1
 DECC$FWRITE_UNBUFFERED                        0      0      0      1  -1
 DECC$FILE_WORLD_DELETE                        0      0      0      1  -1
 DECC$SSIO                                     0      0      0      1  -1
 DECC$SSIO_FOC                                 0      0      0      1  -1
 DECC$EXIT_AFTER_FAILED_EXEC                   0      0      0      1  -1
 DECC$SETVBUF_BUFFERED                         0      0      0      1  -1

** C RTL features that cannot be set by API
 ---------- C RTL Feature  Name ----------   Cur    Def    Min    Max Ini
 DECC$EFS_PRESERVE_CASE                        0      0      0      2  -1
 DECC$DISABLE_RTL_TRACING                      0      0      0      1   0
 
Looks fairly *default* to me.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/19/2008 12:52:34 PM
Mister VAXman,

You really need to provide more info about the exact difference in
behaviour.  DIR/FULL of the output file on both versions, and
description of the exact difference in the outputted data.

Does your data contain any characters about value 128 ? (for instance
'�').  CC/UNSIGNED vs CC will make a big difference because CC will
automatically chop the high order bit off all your bytes being treated
as "char". Using CC/UNSIGNED won't.

Perhaps on your old platform, CC/UNSIGED was the default whereas on the
new one it isn't (or vice-versa).

Note that CC/UNSIGNED has some implications when expecting negative
values from a read operation. You need to use feof(file) to test for end
of file, because you would never get a "-1" as a character value.
0
1/19/2008 1:48:28 PM
In article <4792008b$0$16154$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
>
>Mister VAXman,
>
>You really need to provide more info about the exact difference in
>behaviour.  DIR/FULL of the output file on both versions, and
>description of the exact difference in the outputted data.

This is all screen output; not file.  Actually, it's not even screen
output.  It's an app that fills a glob of memory that some other app
then reads and puts on the screen.  The error is a single byte within
this chunk of memory.  



>Does your data contain any characters about value 128 ? (for instance
>'�').  CC/UNSIGNED vs CC will make a big difference because CC will
>automatically chop the high order bit off all your bytes being treated
>as "char". Using CC/UNSIGNED won't.

Oh?  Since when does 'unsigned char' on longer mean unsigned char?



>Perhaps on your old platform, CC/UNSIGED was the default whereas on the
>new one it isn't (or vice-versa).

Again, this is the same image running on several versions of VMS and
built on an older V7.3-2 system.



>Note that CC/UNSIGNED has some implications when expecting negative
>values from a read operation. You need to use feof(file) to test for end
>of file, because you would never get a "-1" as a character value.

I typically avoid accessing files with C.  If I open a file, it is 
usually accomplished with RMS.  Only on a rare occcasion will I use
C's file I/O and only if it is to read something very simple which
is used to control some program function... in the case of this app,
it reads a file and if it has the word DEBUG, the program uses some
statically defined memory area instead of a malloc()ed region which
makes it easier to debug. In either case, the erroneous results are
the same.

Anyway, I have to get back to this debugging session.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/19/2008 2:36:04 PM
In article <momkj.1$LF1.0@newsfe11.lga>, VAXman-  @SendSpamHere.ORG 
wrote:

> I am busy trying to find the culprit in the file.  I know that somewhere,
> one byte is being written incorrectly.  I've been trying to isolate it by
> using a watchpoint.  It's an inordinately slow process because there is a
> very large regression suite to run before the error occurs.  Once there,
> I can delve in deeper.

I'm perhaps mentioning the obvious here, but is there an easy way to 
feed data into the app without going through the whole of the regression 
suite?

-- 
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~sture/ovms-bookmarks.html
0
1/19/2008 9:39:51 PM
Chris Scheers wrote:
> VAXman- @SendSpamHere.ORG wrote:
>> From the WTF department!  (WTF: What the fuck!)
>>
>> I have an application that is written in 'C'.  It works flawlessly under
>> OpenVMS Alpha V7.3-2 and V8.2.  However, I just ran this same executable
>> on V8.3.  It's a mess.  Because it is the same executable as run on 
>> the other VMS versions, I'd conclude that there's something SERIOUSLY 
>> horked
>> in the C RTL on V8.3.
> 
> Not necessarily.
> 
> A common problem in C is to use the address of a local stack variable in 
> a context that survives past the execution of the routine that defined 
> the variable.  For example, using local stack based IOSB with a $QIO 
> that completes after the current routine returns.
> 
> The suspect stack locations may or may not be trashed or accessed by 
> subsequent calls.  If not, you lucked out and the program runs.

I don't think that the 8.3 CRTL is "horked" (actually I don't know
what that word means, but I can sense the direction).

But I find it hard to believe that Brian would forget something
as described above.

Arne
0
arne6 (9808)
1/20/2008 3:46:54 AM
JF Mezei wrote:
> Does your data contain any characters about value 128 ? (for instance
> '�').  CC/UNSIGNED vs CC will make a big difference because CC will
> automatically chop the high order bit off all your bytes being treated
> as "char".

??

$ type uc.c
#include <stdio.h>

int main(int argc,char *argv[])
{
    char c = 0xFF;
    printf("%d %02x\n", c, c & 0xFF);
    return 0;
}
$ cc uc
$ link uc
$ run uc
-1 ff
$ cc/unsigned uc
$ link uc
$ run uc
255 ff

No bits are chopped off.

> Note that CC/UNSIGNED has some implications when expecting negative
> values from a read operation. You need to use feof(file) to test for end
> of file, because you would never get a "-1" as a character value.

??

getchar/getc returns int not char.

Arne

0
arne6 (9808)
1/20/2008 3:56:53 AM
Arne Vajh�j wrote:

> No bits are chopped off.


I swear, it used to do that.  But it appears it doesn't do this anymore.
Or maybe it happened only in my different dimension where things are
always slightly different from the real world.


char mychar = '�' ;
printf("Mychar=%c", mychar);

used to emit an "i"   (� with the high order bit chopped off)
but when compiled with /unsigned it would print properly. But I just
tried it, and the bits are no longer chopped off when printed.


Also, remember that character comparisons still need /unsigned to work
properly otherwise "�" will be seen as a negative value and this smaller
than "a" which isn't correct.
0
1/20/2008 4:42:03 AM
Hein RMS van den Heuvel wrote:

> On Jan 17, 5:32�pm, VAXman-  @SendSpamHere.ORG wrote:
> > From the WTF department! �(WTF: What the fuck!)
> 
> http://thedailywtf.com/Default.aspx
> 
> 
> > 
> > I have an application that is written in 'C'. �It works flawlessly
> > under OpenVMS Alpha V7.3-2 and V8.2. �
> 
> I beg to differ. It APPEARS to work flawlesly,
> but that was pure bad luck.
> 
> > However, I just ran this same executable on V8.3. �It's a mess. �
> 
> Now there's a fine concise error description for us chew on!
> What C-RTL version?
> Can you try that C-RTL on 8.2
> Can you try a C-CRTL borrowed from 8.2 on 8.3 using some logical
> names?
> 
> Speaking of logical names.... the C-RTL is willing to change behaviour
> drastically based on logical names. Was there an environmental change,
> different DECC$* logicals between teh 8.2 and 8.3 testbed?
> 
> > Because it is the same executable as run on the
> > other VMS versions, I'd conclude that there's something SERIOUSLY
> > horked in the C RTL on V8.3.
> 
> 65,536 other happy programs beg to differ.
> 
> Good luck!
> Hein.

I tend to agree having just fixed a 14 year old error yesterday. A
boundary case which had never happend before!

I'm a greater believer in the maxim 'it doesn't really work; you just
haven't found the problem yet'. It's even caused me the occasional
sleepless night.

Hope you get it sorted Brian.

Cheers - Dave

PS. Finished reading the thread before hitting the Send button. It does
indeed read like a subtle change in the RTL.

-- 

0
nospam109 (47)
1/20/2008 7:53:52 AM
In article <4792c682$0$90276$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>
>
>JF Mezei wrote:
>> Does your data contain any characters about value 128 ? (for instance
>> '�').  CC/UNSIGNED vs CC will make a big difference because CC will
>> automatically chop the high order bit off all your bytes being treated
>> as "char".
>
>??
>
>$ type uc.c
>#include <stdio.h>
>
>int main(int argc,char *argv[])
>{
>    char c = 0xFF;
>    printf("%d %02x\n", c, c & 0xFF);
>    return 0;

Well, I don't often use %d.  I prefer to see hexadecimal.  In fact, my
DBG$INIT does a SET RADIX HEX because I can't stand to look at address
values as decimal.  It pisses me off to this day that the values in a
Macro listing on Alpha are in decimal.  Kudos for the changes to Macro
in the AMacro V5 compiler, BTW!      

As a macro programmer, I am quite cognizant of signed/unsigned.  FWIW,
the above could also have included:

    printf("%d %u %02x\n", c, c & 0xFF, c & 0xFF);

I've never liked the C RTL format specifiers.  When in doubt, I use the
SYS$FAO.  I tend to only use sprintf() if what I'm formatting is simple
string data.   

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/20/2008 12:31:54 PM
In article <5vgd0fF1lptoqU1@mid.individual.net>, "David Weatherall" <nospam@nowheren.no.how> writes:
>
>
>Hein RMS van den Heuvel wrote:
>
>> On Jan 17, 5:32�pm, VAXman-  @SendSpamHere.ORG wrote:
>> > From the WTF department! �(WTF: What the fuck!)
>> 
>> http://thedailywtf.com/Default.aspx
>> 
>> 
>> > 
>> > I have an application that is written in 'C'. �It works flawlessly
>> > under OpenVMS Alpha V7.3-2 and V8.2. �
>> 
>> I beg to differ. It APPEARS to work flawlesly,
>> but that was pure bad luck.
>> 
>> > However, I just ran this same executable on V8.3. �It's a mess. �
>> 
>> Now there's a fine concise error description for us chew on!
>> What C-RTL version?
>> Can you try that C-RTL on 8.2
>> Can you try a C-CRTL borrowed from 8.2 on 8.3 using some logical
>> names?
>> 
>> Speaking of logical names.... the C-RTL is willing to change behaviour
>> drastically based on logical names. Was there an environmental change,
>> different DECC$* logicals between teh 8.2 and 8.3 testbed?
>> 
>> > Because it is the same executable as run on the
>> > other VMS versions, I'd conclude that there's something SERIOUSLY
>> > horked in the C RTL on V8.3.
>> 
>> 65,536 other happy programs beg to differ.
>> 
>> Good luck!
>> Hein.
>
>I tend to agree having just fixed a 14 year old error yesterday. A
>boundary case which had never happend before!
>
>I'm a greater believer in the maxim 'it doesn't really work; you just
>haven't found the problem yet'. It's even caused me the occasional
>sleepless night.
>
>Hope you get it sorted Brian.
>
>Cheers - Dave
>
>PS. Finished reading the thread before hitting the Send button. It does
>indeed read like a subtle change in the RTL.

There's more than a subtle change in the RTL.

$ pipe an/im sys$share:decc$shr.exe | sea sys$pipe symbol: > v732decc.txt
$ pipe an/im dka200:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > v82decc.txt
$ pipe an/im dka300:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > v83decc.txt

v732decc=> 3262 symbols/size 5261
v82decc => 3320 symbols/size 5386 :: 58 new symbols/125 more blocks than V732
v83decc => 3344 symbols/size 5519 :: 24 new symbols/133 more blocks than V82

It's a long MLK weekend and there's more more left to do in the debugger.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/20/2008 12:56:01 PM
In article <BxHkj.2$%Z4.1@newsfe11.lga>, VAXman-  @SendSpamHere.ORG 
wrote:

> In article <5vgd0fF1lptoqU1@mid.individual.net>, "David Weatherall" 
> <nospam@nowheren.no.how> writes:


> >PS. Finished reading the thread before hitting the Send button. It does
> >indeed read like a subtle change in the RTL.
> 
> There's more than a subtle change in the RTL.
> 
> $ pipe an/im sys$share:decc$shr.exe | sea sys$pipe symbol: > v732decc.txt
> $ pipe an/im dka200:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > 
> v82decc.txt
> $ pipe an/im dka300:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > 
> v83decc.txt
> 
> v732decc=> 3262 symbols/size 5261
> v82decc => 3320 symbols/size 5386 :: 58 new symbols/125 more blocks than V732
> v83decc => 3344 symbols/size 5519 :: 24 new symbols/133 more blocks than V82
> 
> It's a long MLK weekend and there's more more left to do in the debugger.

Of course there are a lot of new symbols, and the version dependency 
tables at the end of the CRTL manual should tell you what at least most 
of them are (though likely some are for internal use only).  But new 
symbols aren't all that likely to be the cause of you problem since 
you've already shown us you're only using a dozen or so symbols in your 
image.

I don't think you've yet stated the ECO level of the two CRTLs which, 
if different, could be relevant, or could reveal version-specific 
differences.  For example VMS83A_ACRTL-V0200 has changes to the printf 
family of functions related to wide and multi-byte characters.  I don't 
see mention of the same bug fix in any of the v8.2 CRTL release notes, 
which means the bug might have been introduced in v8.3.  Extracting the 
image from the various ECO PCSI kits and rotating them in the same way 
you did for the 8.2 image would be the obvious way to prove whether any 
of them makes a difference.

Of course you may be fighting an entirely new bug they haven't found 
and fixed for you yet :-).  Good luck.

-- 
Posted via a free Usenet account from http://www.teranews.com

0
craigberry (308)
1/20/2008 4:00:30 PM
VAXman- @SendSpamHere.ORG wrote:
> There's more than a subtle change in the RTL.
> 
> $ pipe an/im sys$share:decc$shr.exe | sea sys$pipe symbol: > v732decc.txt
> $ pipe an/im dka200:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > v82decc.txt
> $ pipe an/im dka300:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > v83decc.txt
> 
> v732decc=> 3262 symbols/size 5261
> v82decc => 3320 symbols/size 5386 :: 58 new symbols/125 more blocks than V732
> v83decc => 3344 symbols/size 5519 :: 24 new symbols/133 more blocks than V82

New functionality is to both be expected and should not break
existing functionality.

Arne
0
arne6 (9808)
1/20/2008 9:30:30 PM
In article <4793bd71$0$90268$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>
>
>VAXman- @SendSpamHere.ORG wrote:
>> There's more than a subtle change in the RTL.
>> 
>> $ pipe an/im sys$share:decc$shr.exe | sea sys$pipe symbol: > v732decc.txt
>> $ pipe an/im dka200:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > v82decc.txt
>> $ pipe an/im dka300:[vms$common.syslib]decc$shr.exe | sea sys$pipe symbol: > v83decc.txt
>> 
>> v732decc=> 3262 symbols/size 5261
>> v82decc => 3320 symbols/size 5386 :: 58 new symbols/125 more blocks than V732
>> v83decc => 3344 symbols/size 5519 :: 24 new symbols/133 more blocks than V82
>
>New functionality is to both be expected and should not break
>existing functionality.

It does and I found it!  It wasn't in the application but in the program
used to generate the regression data and the problem is already document-
ed in the release notes of the VMS83A_ACRTL-V0400 patch:

  5.2.5  Function mktime() Fix
       
       5.2.5.1  Problem Description:
         
       Modules compiled under OpenVMS version 7.3-2 use the
       short version of struct tm when making a call to mktime()
       on an OpenVMs version 8.3 system.  The mktime() API
       internally creates a temporary copy of a struct tm then
       calls localtime_r().  In our environment, the module
       containing the mktime() function was compiled using 8.3
       semantics.  This resulted in a longer struct tm.
        
       At the end of the mktime() function the temporary struct
       tm is copied onto the input struct tm.  This results in
       copying a longer struct tm over a short struct tm.

I needed to find it first before applying any patch.  I changed the code 
in the regression test to add some padding after the tm struct where it
is called out.  The bug in the mktime() was writing over a variable that
was eventually used in the length of a descriptor.  The code was actually
compiled well before V7.3-2.  The tm struct was 36 bytes in length and the
new tm is 44 bytes -- 2 longwords longer.

Now, if C used descriptors, this might not be a problem.  As is, there is
nothing to tell the mktime() function the length of the tm struct being
passed to it.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/20/2008 10:15:07 PM
VAXman- @SendSpamHere.ORG wrote:

>        At the end of the mktime() function the temporary struct
>        tm is copied onto the input struct tm.  This results in
>        copying a longer struct tm over a short struct tm.


I am impressed. Mrs VAXman should give you a great massage to celebrate
your success in hunting down that bug.  This was a truly obscure bug and
its hunt must have been quite the challenge. Congrats on finding it.
0
1/20/2008 11:30:55 PM
In article <craigberry-FFA012.20243518012008@free.teranews.com>, "Craig A. Berry" <craigberry@mac.com.spamfooler> writes:
> In article 
> <c03f4b2a-f185-480c-945c-0392d86b4b4f@s13g2000prd.googlegroups.com>,
>  Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> wrote:
> 
>> On Jan 18, 11:58�am, VAXman-  @SendSpamHere.ORG wrote:
>> > This code doesn't use many C RTL fucntions. �
> 
> And that's what led you to suspect the CRTL first?
> 
   Don't you know VAXMAN always writes perfect code?  8-)

   Actualy, since I took Friday off, I'm sitting here following this
   thread on Monday (we don't get MLK's day off), with a good bit of
   interest in just what the bug turns out to be (I hope its been
   posted already).

   I'd suspect some small change documented in the Release Notes, who's
   small affect in this case isn't obvious.  If he'd recompiled the code
   I'd think it might be in optimization, but since he's running the
   same image I agree with him in suspecting the RTL.
   
0
koehler2 (8314)
1/21/2008 2:28:06 PM
In article <fmr04f$ou2$1@reader2.panix.com>, John F <johnf@please.see.sig.for.address.com> writes:
> 
> Sounds like some straightforward ansi-standard C program.
> You use descrip.h, ssdef.h, or any other vms stuff?
> If not, and if it is straight ansi C, try downloading
> to a linux box, or any other handy environment that'll
> compile and run standard C for you.  You may get lucky
> and watch it blow up, rather than run to completion with
> the wrong results.  That should be a lot easier to debug.
> (And try compiling with the -O3 -pedantic -Wall switches.)

   Suspecting a Linux C compiler to be more "standard" than DEC C,
   or the debugging evnironment to be more useful than that provided
   by VMS seems to be a bit of a strech.

   But certainly in determining why a change in VMS version causes a
   change in behaviour it seems to be irrelavent.

0
koehler2 (8314)
1/21/2008 2:32:22 PM
In article <Q61MLM6RmK0e@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>
>
>In article <craigberry-FFA012.20243518012008@free.teranews.com>, "Craig A. Berry" <craigberry@mac.com.spamfooler> writes:
>> In article 
>> <c03f4b2a-f185-480c-945c-0392d86b4b4f@s13g2000prd.googlegroups.com>,
>>  Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> wrote:
>> 
>>> On Jan 18, 11:58�am, VAXman-  @SendSpamHere.ORG wrote:
>>> > This code doesn't use many C RTL fucntions. �
>> 
>> And that's what led you to suspect the CRTL first?
>> 
>   Don't you know VAXMAN always writes perfect code?  8-)

Damn straight!  'Tis my job to _right_ code for a living!



>   Actualy, since I took Friday off, I'm sitting here following this
>   thread on Monday (we don't get MLK's day off), with a good bit of
>   interest in just what the bug turns out to be (I hope its been
>   posted already).
>
>   I'd suspect some small change documented in the Release Notes, who's
>   small affect in this case isn't obvious.  If he'd recompiled the code
>   I'd think it might be in optimization, but since he's running the
>   same image I agree with him in suspecting the RTL.

Bob, I did post the findings... 

Here is a Google link just in case your NNTP server can't find the message.

http://groups.google.com/group/comp.os.vms/msg/c23441a248bd3748

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/21/2008 4:12:02 PM
VAXman- @SendSpamHere.ORG wrote:
> It does and I found it!  It wasn't in the application but in the program
> used to generate the regression data and the problem is already document-
> ed in the release notes of the VMS83A_ACRTL-V0400 patch:
> 
>   5.2.5  Function mktime() Fix
>        
>        5.2.5.1  Problem Description:
>          
>        Modules compiled under OpenVMS version 7.3-2 use the
>        short version of struct tm when making a call to mktime()
>        on an OpenVMs version 8.3 system.  The mktime() API
>        internally creates a temporary copy of a struct tm then
>        calls localtime_r().  In our environment, the module
>        containing the mktime() function was compiled using 8.3
>        semantics.  This resulted in a longer struct tm.
>         
>        At the end of the mktime() function the temporary struct
>        tm is copied onto the input struct tm.  This results in
>        copying a longer struct tm over a short struct tm.
> 
> I needed to find it first before applying any patch.  I changed the code 
> in the regression test to add some padding after the tm struct where it
> is called out.  The bug in the mktime() was writing over a variable that
> was eventually used in the length of a descriptor.  The code was actually
> compiled well before V7.3-2.  The tm struct was 36 bytes in length and the
> new tm is 44 bytes -- 2 longwords longer.

That is a really bad thing they did there.

In reality it means that any program that uses struct tm need to be
rebuild when moved from VMS 7.3-2 to 8.3 !

Very non-VMSish !

Arne
0
arne6 (9808)
1/21/2008 7:32:24 PM
In article <LJPkj.2$7S1.0@newsfe12.lga>,   VAXman-  @SendSpamHere.ORG writes:

>        At the end of the mktime() function the temporary struct
>        tm is copied onto the input struct tm.  This results in
>        copying a longer struct tm over a short struct tm.

Well Brian, I hope _that_ will convince you not to be such a fan of C !
0
Kilgallen (2738)
1/21/2008 9:33:42 PM
In article <+N4hJB85poH2@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>
>
>In article <LJPkj.2$7S1.0@newsfe12.lga>,   VAXman-  @SendSpamHere.ORG writes:
>
>>        At the end of the mktime() function the temporary struct
>>        tm is copied onto the input struct tm.  This results in
>>        copying a longer struct tm over a short struct tm.
>
>Well Brian, I hope _that_ will convince you not to be such a fan of C !

Now Larry, you know me better than that!  I'm no fan of C.  It was an evil
thrust upon me -- like Micro$oft thrusting into unwilling orifices causing
great discomfort that no colonic irrigation can purge away.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/22/2008 12:39:44 AM
In article <4794f341$0$90263$14726298@news.sunsite.dk>,
 Arne Vajh�j <arne@vajhoej.dk> wrote:

> VAXman- @SendSpamHere.ORG wrote:
> > It does and I found it!  It wasn't in the application but in the program
> > used to generate the regression data and the problem is already document-
> > ed in the release notes of the VMS83A_ACRTL-V0400 patch:
> > 
> >   5.2.5  Function mktime() Fix
> >        
> >        5.2.5.1  Problem Description:
> >          
> >        Modules compiled under OpenVMS version 7.3-2 use the
> >        short version of struct tm when making a call to mktime()
> >        on an OpenVMs version 8.3 system.  The mktime() API
> >        internally creates a temporary copy of a struct tm then
> >        calls localtime_r().  In our environment, the module
> >        containing the mktime() function was compiled using 8.3
> >        semantics.  This resulted in a longer struct tm.
> >         
> >        At the end of the mktime() function the temporary struct
> >        tm is copied onto the input struct tm.  This results in
> >        copying a longer struct tm over a short struct tm.
> > 
> > I needed to find it first before applying any patch.  I changed the code 
> > in the regression test to add some padding after the tm struct where it
> > is called out.  The bug in the mktime() was writing over a variable that
> > was eventually used in the length of a descriptor.  The code was actually
> > compiled well before V7.3-2.  The tm struct was 36 bytes in length and the
> > new tm is 44 bytes -- 2 longwords longer.
> 
> That is a really bad thing they did there.
> 
> In reality it means that any program that uses struct tm need to be
> rebuild when moved from VMS 7.3-2 to 8.3 !
> 
> Very non-VMSish !

Well, this goof apparently consisted of merely compiling one module in 
the CRTL with the standard headers.  Look at the following sections from 
time.h:

**  - Future VMS releases will get a longer tm structure possibly with
**    changed/filler names, to make all objects of tm the same length,
**    which may force recompilation of all modules using tm.
**  - Macro _TM_SHORT will force short tm
**  - Macro _TM_LONG will force long tm
**

[and later]

#   if __CRTL_VER >= 80300000 || defined _TM_LONG || \
       defined __TM_CXX_NEED_FILLER_NAMES
        /* Longer tm, but non-polluting BSD member names */
#       define __TM_DEF_BSD_FILLER_NAMES

[and later still]

#elif defined __TM_DEF_BSD_FILLER_NAMES
   /* BSD tm member extensions, non-polluting namespace  */
   long __tm_gmtoff; /* offset from UTC in seconds       */
   char *__tm_zone;  /* timezone abbreviation            */


So clearly compiling under v8.3 gives you a couple more structure 
members than you would have had before, at least unless you had 
explicitly defined the _TM_LONG macro before.

I suspect that it's much harder, if not impossible, to build a v8.3 
CRTL on older VMS versions than has been the case in some eras.  So 
many of the new goodies depend on OS features, RMS features, etc.  They 
did make a mistake in not preserving upward compatibility, but I can 
see how it happened.  I was hoping that this meant the 2038 bug had 
been fixed for anything compiled on v8.3 and later, but that appears to 
be unrelated and will be another compatibility rat's nest in our 
future.

-- 
Posted via a free Usenet account from http://www.teranews.com

0
craigberry (308)
1/22/2008 4:49:40 AM
In article <kXalj.3$oZ1.0@newsfe09.lga>, VAXman-  @SendSpamHere.ORG 
wrote:

> In article <+N4hJB85poH2@eisner.encompasserve.org>, Kilgallen@SpamCop.net 
> (Larry Kilgallen) writes:
> >
> >
> >In article <LJPkj.2$7S1.0@newsfe12.lga>,   VAXman-  @SendSpamHere.ORG 
> >writes:
> >
> >>        At the end of the mktime() function the temporary struct
> >>        tm is copied onto the input struct tm.  This results in
> >>        copying a longer struct tm over a short struct tm.
> >
> >Well Brian, I hope _that_ will convince you not to be such a fan of C !
> 
> Now Larry, you know me better than that!  I'm no fan of C.  It was an evil
> thrust upon me -- like Micro$oft thrusting into unwilling orifices causing
> great discomfort that no colonic irrigation can purge away.

So what was your favourite language (apart from macro) before that?

-- 
Paul Sture
0
1/22/2008 8:07:47 AM
In article <4794f341$0$90263$14726298@news.sunsite.dk>,
 Arne Vajh�j <arne@vajhoej.dk> wrote:

> VAXman- @SendSpamHere.ORG wrote:
> > It does and I found it!  It wasn't in the application but in the program
> > used to generate the regression data and the problem is already document-
> > ed in the release notes of the VMS83A_ACRTL-V0400 patch:
> > 
> >   5.2.5  Function mktime() Fix
> >        
> >        5.2.5.1  Problem Description:
> >          
> >        Modules compiled under OpenVMS version 7.3-2 use the
> >        short version of struct tm when making a call to mktime()
> >        on an OpenVMs version 8.3 system.  The mktime() API
> >        internally creates a temporary copy of a struct tm then
> >        calls localtime_r().  In our environment, the module
> >        containing the mktime() function was compiled using 8.3
> >        semantics.  This resulted in a longer struct tm.
> >         
> >        At the end of the mktime() function the temporary struct
> >        tm is copied onto the input struct tm.  This results in
> >        copying a longer struct tm over a short struct tm.
> > 
> > I needed to find it first before applying any patch.  I changed the code 
> > in the regression test to add some padding after the tm struct where it
> > is called out.  The bug in the mktime() was writing over a variable that
> > was eventually used in the length of a descriptor.  The code was actually
> > compiled well before V7.3-2.  The tm struct was 36 bytes in length and the
> > new tm is 44 bytes -- 2 longwords longer.
> 
> That is a really bad thing they did there.
> 
> In reality it means that any program that uses struct tm need to be
> rebuild when moved from VMS 7.3-2 to 8.3 !

Doesn't it just mean that the patch needs to be installed on V8.3 
systems to eliminate the bug?  I don't see a need to rebuild.
 
> Very non-VMSish !

If you decide to only use the VMS versions with zero bugs, you'll have 
to find another OS.
0
1/22/2008 12:01:57 PM
In article <paul.sture.nospam-581C84.09074722012008@mac.sture.ch>, "P. Sture" <paul.sture.nospam@hispeed.ch> writes:
>
>
>In article <kXalj.3$oZ1.0@newsfe09.lga>, VAXman-  @SendSpamHere.ORG 
>wrote:
>
>> In article <+N4hJB85poH2@eisner.encompasserve.org>, Kilgallen@SpamCop.net 
>> (Larry Kilgallen) writes:
>> >
>> >
>> >In article <LJPkj.2$7S1.0@newsfe12.lga>,   VAXman-  @SendSpamHere.ORG 
>> >writes:
>> >
>> >>        At the end of the mktime() function the temporary struct
>> >>        tm is copied onto the input struct tm.  This results in
>> >>        copying a longer struct tm over a short struct tm.
>> >
>> >Well Brian, I hope _that_ will convince you not to be such a fan of C !
>> 
>> Now Larry, you know me better than that!  I'm no fan of C.  It was an evil
>> thrust upon me -- like Micro$oft thrusting into unwilling orifices causing
>> great discomfort that no colonic irrigation can purge away.
>
>So what was your favourite language (apart from macro) before that?

Math and music.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/22/2008 1:16:04 PM
In article <rdeininger-AD52B8.07015722012008@70-3-168-216.area5.spcsdns.net>, Robert Deininger <rdeininger@mindspring.dot.com> writes:
>
>
>In article <4794f341$0$90263$14726298@news.sunsite.dk>,
> Arne Vajh�j <arne@vajhoej.dk> wrote:
>
>> VAXman- @SendSpamHere.ORG wrote:
>> > It does and I found it!  It wasn't in the application but in the program
>> > used to generate the regression data and the problem is already document-
>> > ed in the release notes of the VMS83A_ACRTL-V0400 patch:
>> > 
>> >   5.2.5  Function mktime() Fix
>> >        
>> >        5.2.5.1  Problem Description:
>> >          
>> >        Modules compiled under OpenVMS version 7.3-2 use the
>> >        short version of struct tm when making a call to mktime()
>> >        on an OpenVMs version 8.3 system.  The mktime() API
>> >        internally creates a temporary copy of a struct tm then
>> >        calls localtime_r().  In our environment, the module
>> >        containing the mktime() function was compiled using 8.3
>> >        semantics.  This resulted in a longer struct tm.
>> >         
>> >        At the end of the mktime() function the temporary struct
>> >        tm is copied onto the input struct tm.  This results in
>> >        copying a longer struct tm over a short struct tm.
>> > 
>> > I needed to find it first before applying any patch.  I changed the code 
>> > in the regression test to add some padding after the tm struct where it
>> > is called out.  The bug in the mktime() was writing over a variable that
>> > was eventually used in the length of a descriptor.  The code was actually
>> > compiled well before V7.3-2.  The tm struct was 36 bytes in length and the
>> > new tm is 44 bytes -- 2 longwords longer.
>> 
>> That is a really bad thing they did there.
>> 
>> In reality it means that any program that uses struct tm need to be
>> rebuild when moved from VMS 7.3-2 to 8.3 !
>
>Doesn't it just mean that the patch needs to be installed on V8.3 
>systems to eliminate the bug?  I don't see a need to rebuild.

Correct!

However, I don't tend to install patches and most of the disclaimers in
the patch kits say not to install a patch unless experiencing the prob-
lem(s) address by the patch.

When I first tested the application and looked through the .MAP files,
I didn't see any DECC$MKTIME() references.  Eventually, and after days
of debugging, I found that it wasn't the application itself that was in
error but the program that is used to feed data to it.  It _did_ employ
mktime().



>> Very non-VMSish !
>
>If you decide to only use the VMS versions with zero bugs, you'll have 
>to find another OS.

:)

I use VMS because 

  lim VMS(bugs) 
bugs->0

is small. 

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/22/2008 1:33:29 PM
On Tue, 22 Jan 2008 05:16:04 -0800, VAXman- <@SendSpamHere.ORG> wrote:

> In article <paul.sture.nospam-581C84.09074722012008@mac.sture.ch>, "P.  
> Sture" <paul.sture.nospam@hispeed.ch> writes:
>>
>>
>> In article <kXalj.3$oZ1.0@newsfe09.lga>, VAXman-  @SendSpamHere.ORG
>> wrote:
>>
>>> In article <+N4hJB85poH2@eisner.encompasserve.org>,  
>>> Kilgallen@SpamCop.net
>>> (Larry Kilgallen) writes:
>>> >
>>> >
>>> >In article <LJPkj.2$7S1.0@newsfe12.lga>,   VAXman-  @SendSpamHere.ORG
>>> >writes:
>>> >
>>> >>        At the end of the mktime() function the temporary struct
>>> >>        tm is copied onto the input struct tm.  This results in
>>> >>        copying a longer struct tm over a short struct tm.
>>> >
>>> >Well Brian, I hope _that_ will convince you not to be such a fan of C  
>>> !
>>>
>>> Now Larry, you know me better than that!  I'm no fan of C.  It was an  
>>> evil
>>> thrust upon me -- like Micro$oft thrusting into unwilling orifices  
>>> causing
>>> great discomfort that no colonic irrigation can purge away.
>>
>> So what was your favourite language (apart from macro) before that?
>
> Math and music.
>
You must have read Hesse's, Die Glasperlenspieler  (The Bead Players)


-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
1/22/2008 1:48:08 PM
In article <op.t5b3aifhhv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:
>
>
>On Tue, 22 Jan 2008 05:16:04 -0800, VAXman- <@SendSpamHere.ORG> wrote:
>
>> In article <paul.sture.nospam-581C84.09074722012008@mac.sture.ch>, "P.  
>> Sture" <paul.sture.nospam@hispeed.ch> writes:
>>>
>>>
>>> In article <kXalj.3$oZ1.0@newsfe09.lga>, VAXman-  @SendSpamHere.ORG
>>> wrote:
>>>
>>>> In article <+N4hJB85poH2@eisner.encompasserve.org>,  
>>>> Kilgallen@SpamCop.net
>>>> (Larry Kilgallen) writes:
>>>> >
>>>> >
>>>> >In article <LJPkj.2$7S1.0@newsfe12.lga>,   VAXman-  @SendSpamHere.ORG
>>>> >writes:
>>>> >
>>>> >>        At the end of the mktime() function the temporary struct
>>>> >>        tm is copied onto the input struct tm.  This results in
>>>> >>        copying a longer struct tm over a short struct tm.
>>>> >
>>>> >Well Brian, I hope _that_ will convince you not to be such a fan of C  
>>>> !
>>>>
>>>> Now Larry, you know me better than that!  I'm no fan of C.  It was an  
>>>> evil
>>>> thrust upon me -- like Micro$oft thrusting into unwilling orifices  
>>>> causing
>>>> great discomfort that no colonic irrigation can purge away.
>>>
>>> So what was your favourite language (apart from macro) before that?
>>
>> Math and music.
>>
>You must have read Hesse's, Die Glasperlenspieler  (The Bead Players)

No but I will put it on the "to read" list.

I wonder if you are familiar with the term "math rock".  Not a genre I am
fond of but I can appreciate what those who have developed the genre are
attempting to do.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/22/2008 3:04:51 PM
On Tue, 22 Jan 2008 07:04:51 -0800, VAXman- <@SendSpamHere.ORG> wrote:

> In article <op.t5b3aifhhv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden"  
> <tom@kednos.company> writes:
>>
>>
>> On Tue, 22 Jan 2008 05:16:04 -0800, VAXman- <@SendSpamHere.ORG> wrote:
>>
>>> In article <paul.sture.nospam-581C84.09074722012008@mac.sture.ch>, "P.
>>> Sture" <paul.sture.nospam@hispeed.ch> writes:
>>>>
>>>>
>>>> In article <kXalj.3$oZ1.0@newsfe09.lga>, VAXman-  @SendSpamHere.ORG
>>>> wrote:
>>>>
>>>>> In article <+N4hJB85poH2@eisner.encompasserve.org>,
>>>>> Kilgallen@SpamCop.net
>>>>> (Larry Kilgallen) writes:
>>>>> >
>>>>> >
>>>>> >In article <LJPkj.2$7S1.0@newsfe12.lga>,   VAXman-   
>>>>> @SendSpamHere.ORG
>>>>> >writes:
>>>>> >
>>>>> >>        At the end of the mktime() function the temporary struct
>>>>> >>        tm is copied onto the input struct tm.  This results in
>>>>> >>        copying a longer struct tm over a short struct tm.
>>>>> >
>>>>> >Well Brian, I hope _that_ will convince you not to be such a fan of  
>>>>> C
>>>>> !
>>>>>
>>>>> Now Larry, you know me better than that!  I'm no fan of C.  It was an
>>>>> evil
>>>>> thrust upon me -- like Micro$oft thrusting into unwilling orifices
>>>>> causing
>>>>> great discomfort that no colonic irrigation can purge away.
>>>>
>>>> So what was your favourite language (apart from macro) before that?
>>>
>>> Math and music.
>>>
>> You must have read Hesse's, Die Glasperlenspieler  (The Bead Players)
>
> No but I will put it on the "to read" list.
>
> I wonder if you are familiar with the term "math rock".  Not a genre I am
> fond of but I can appreciate what those who have developed the genre are
> attempting to do.
>
Not until now.  Doesn't sound like my cup of tea.


-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
1/22/2008 4:21:58 PM
Robert Deininger wrote:
> In article <4794f341$0$90263$14726298@news.sunsite.dk>,
>  Arne Vajh�j <arne@vajhoej.dk> wrote:
>> That is a really bad thing they did there.
>>
>> In reality it means that any program that uses struct tm need to be
>> rebuild when moved from VMS 7.3-2 to 8.3 !
> 
> Doesn't it just mean that the patch needs to be installed on V8.3 
> systems to eliminate the bug?  I don't see a need to rebuild.
>  
>> Very non-VMSish !
> 
> If you decide to only use the VMS versions with zero bugs, you'll have 
> to find another OS.

Apparently it has been recognized as a bug.

But my comments still apply to the original code.

Arne
0
arne6 (9808)
1/23/2008 2:08:06 AM
Craig A. Berry wrote:
>                                                                They 
> did make a mistake in not preserving upward compatibility, but I can 
> see how it happened.

Stuff like this happen all the time on other platforms.

But not on VMS.

Arne
0
arne6 (9808)
1/23/2008 2:10:08 AM
In article <4796a1f6$0$90263$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
> Craig A. Berry wrote:
>>                                                                They 
>> did make a mistake in not preserving upward compatibility, but I can 
>> see how it happened.
> 
> Stuff like this happen all the time on other platforms.
> 
> But not on VMS.

The problem is that this is not VMS, it is the language-specific CRTL.
VMS development has consistency checks to ensure Starlet constructs
are backward compatible.
0
Kilgallen (2738)
1/23/2008 5:42:07 PM
On Wed, 23 Jan 2008 09:42:07 -0800, Larry Kilgallen  =

<Kilgallen@SpamCop.net> wrote:

> In article <4796a1f6$0$90263$14726298@news.sunsite.dk>,  =

> =3D?ISO-8859-1?Q?Arne_Vajh=3DF8j?=3D <arne@vajhoej.dk> writes:
>> Craig A. Berry wrote:
>>>                                                                They
>>> did make a mistake in not preserving upward compatibility, but I can=

>>> see how it happened.
>>
>> Stuff like this happen all the time on other platforms.
>>
>> But not on VMS.
>
> The problem is that this is not VMS, it is the language-specific CRTL.=

> VMS development has consistency checks to ensure Starlet constructs
> are backward compatible.

Having one Starlet source for all languages is the only way to go.


-- =

PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
1/23/2008 10:22:15 PM
In article <mv3lj.4$eD7.1@newsfe11.lga>,   VAXman-  @SendSpamHere.ORG writes:
> Bob, I did post the findings... 
> 

   Yes, I eventually read that far.

0
koehler2 (8314)
1/24/2008 1:32:19 PM
On Jan 21, 1:32 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

> That is a really bad thing they did there.
>
> In reality it means that any program that uses struct tm need to be
> rebuild when moved from VMS 7.3-2 to 8.3 !
>
> Very non-VMSish !
>

Blame the C standards committee, not the OpenVMS developers.
0
yyyc186 (230)
1/24/2008 3:43:54 PM
On Jan 21, 10:49 pm, "Craig A. Berry" <craigbe...@mac.com.spamfooler>
wrote:
>
> I suspect that it's much harder, if not impossible, to build a v8.3
> CRTL on older VMS versions than has been the case in some eras.  So
> many of the new goodies depend on OS features, RMS features, etc.  They
> did make a mistake in not preserving upward compatibility, but I can
> see how it happened.  I was hoping that this meant the 2038 bug had
> been fixed for anything compiled on v8.3 and later, but that appears to
> be unrelated and will be another compatibility rat's nest in our
> future.
>

Until the ANSI C committee comes together, you can't "legally" fix the
2038 bug.  I'm sure they will get around to it in 2036 or so.
0
yyyc186 (230)
1/24/2008 3:49:44 PM
In article <4a1eb22e-94ac-4dc0-b6f5-39aaf3ea0003@k39g2000hsf.googlegroups.com>, yyyc186 <yyyc186@hughes.net> writes:
>
>
>On Jan 21, 10:49 pm, "Craig A. Berry" <craigbe...@mac.com.spamfooler>
>wrote:
>>
>> I suspect that it's much harder, if not impossible, to build a v8.3
>> CRTL on older VMS versions than has been the case in some eras.  So
>> many of the new goodies depend on OS features, RMS features, etc.  They
>> did make a mistake in not preserving upward compatibility, but I can
>> see how it happened.  I was hoping that this meant the 2038 bug had
>> been fixed for anything compiled on v8.3 and later, but that appears to
>> be unrelated and will be another compatibility rat's nest in our
>> future.
>>
>
>Until the ANSI C committee comes together, you can't "legally" fix the
>2038 bug.  I'm sure they will get around to it in 2036 or so.

....but that's only to schedule the formal committee to devise the fix
in 2039. :)

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/24/2008 4:14:16 PM
"yyyc186" <yyyc186@hughes.net> wrote in message 
news:4a1eb22e-94ac-4dc0-b6f5-39aaf3ea0003@k39g2000hsf.googlegroups.com...

> Until the ANSI C committee comes together, you can't "legally" fix the
> 2038 bug.  I'm sure they will get around to it in 2036 or so.

Nothing in the C standard says that time_t is a 32-bit type.
No reason (apart from compatibility) not to promote it to 64-bits
today. Of course, you're out of luck on a VAX but nobody cares
about them, right? 


0
R.Brodie (551)
1/24/2008 4:42:54 PM
yyyc186 wrote:
> On Jan 21, 10:49 pm, "Craig A. Berry" <craigbe...@mac.com.spamfooler>
> wrote:
> 
>>I suspect that it's much harder, if not impossible, to build a v8.3
>>CRTL on older VMS versions than has been the case in some eras.  So
>>many of the new goodies depend on OS features, RMS features, etc.  They
>>did make a mistake in not preserving upward compatibility, but I can
>>see how it happened.  I was hoping that this meant the 2038 bug had
>>been fixed for anything compiled on v8.3 and later, but that appears to
>>be unrelated and will be another compatibility rat's nest in our
>>future.
>>
> 
> 
> Until the ANSI C committee comes together, you can't "legally" fix the
> 2038 bug.  I'm sure they will get around to it in 2036 or so.

Optimist!!!   How about 30 November 2037?

Based on past performance, if the ANSI C committee meets again, we may 
be forced to standardize on a different language!



0
rgilbert88 (4439)
1/24/2008 4:46:46 PM
Richard Brodie wrote:
> "yyyc186" <yyyc186@hughes.net> wrote in message 
> news:4a1eb22e-94ac-4dc0-b6f5-39aaf3ea0003@k39g2000hsf.googlegroups.com...
> 
> 
>>Until the ANSI C committee comes together, you can't "legally" fix the
>>2038 bug.  I'm sure they will get around to it in 2036 or so.
> 
> 
> Nothing in the C standard says that time_t is a 32-bit type.
> No reason (apart from compatibility) not to promote it to 64-bits
> today. Of course, you're out of luck on a VAX but nobody cares
> about them, right? 
> 
> 

VAX?  Of course not!  Hopelessly obsolete!!  The smaller ones make nice 
paperweights!!!  If you want your prompt back the same day, get an Alpha!!!!

ISTR that the VAX instruction set had provisions for doing multiword 
arithmetic if not actual 64 bit ADD, SUBTRACT, MULTIPLY and DIVIDE 
instructions.  IOW it was not terribly difficult to do 64, 96 or 128 bit 
arithmetic if you REALLY needed it.

0
rgilbert88 (4439)
1/24/2008 5:07:34 PM
In article <fnaf6e$shq$1@south.jnrs.ja.net>, "Richard Brodie" <R.Brodie@rl.ac.uk> writes:
> 
> "yyyc186" <yyyc186@hughes.net> wrote in message 
> news:4a1eb22e-94ac-4dc0-b6f5-39aaf3ea0003@k39g2000hsf.googlegroups.com...
> 
>> Until the ANSI C committee comes together, you can't "legally" fix the
>> 2038 bug.  I'm sure they will get around to it in 2036 or so.
> 
> Nothing in the C standard says that time_t is a 32-bit type.
> No reason (apart from compatibility) not to promote it to 64-bits
> today. Of course, you're out of luck on a VAX but nobody cares
> about them, right? 

   Does anything say time_t is signed?

0
koehler2 (8314)
1/24/2008 7:01:16 PM
In article <4798C5D6.4020701@comcast.net>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> ISTR that the VAX instruction set had provisions for doing multiword 
> arithmetic if not actual 64 bit ADD, SUBTRACT, MULTIPLY and DIVIDE 
> instructions.  IOW it was not terribly difficult to do 64, 96 or 128 bit 
> arithmetic if you REALLY needed it.

   Had it, used it, enjoyed it.  But the VAX C and DEC C compilers for
   VAX won't use them for you.

0
koehler2 (8314)
1/24/2008 7:02:23 PM
Bob Koehler wrote:
> In article <4798C5D6.4020701@comcast.net>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
>>ISTR that the VAX instruction set had provisions for doing multiword 
>>arithmetic if not actual 64 bit ADD, SUBTRACT, MULTIPLY and DIVIDE 
>>instructions.  IOW it was not terribly difficult to do 64, 96 or 128 bit 
>>arithmetic if you REALLY needed it.
> 
> 
>    Had it, used it, enjoyed it.  But the VAX C and DEC C compilers for
>    VAX won't use them for you.
> 

If you need these operations, you can "roll your own" in Macro and 
access them from C.  They might even be in a library somewhere. I've 
never needed to use integers that large.  I don't expect ever to need to.

0
rgilbert88 (4439)
1/24/2008 7:29:54 PM
In article <c2d62097-52db-4335-9f8e-148098020cf2@i72g2000hsd.googlegroups.com>, yyyc186 <yyyc186@hughes.net> writes:
> On Jan 21, 1:32 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> 
>> That is a really bad thing they did there.
>>
>> In reality it means that any program that uses struct tm need to be
>> rebuild when moved from VMS 7.3-2 to 8.3 !
>>
>> Very non-VMSish !
>>
> 
> Blame the C standards committee, not the OpenVMS developers.

It is fully within the power of the VMS C developers to make a
mismatch prevent a successful Link or Run command, rather than
bombing strangely in the middle of operations.
0
Kilgallen (2738)
1/24/2008 7:56:06 PM
In article <$mMJA$2fUG6g@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>
>
>In article <c2d62097-52db-4335-9f8e-148098020cf2@i72g2000hsd.googlegroups.com>, yyyc186 <yyyc186@hughes.net> writes:
>> On Jan 21, 1:32 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
>> 
>>> That is a really bad thing they did there.
>>>
>>> In reality it means that any program that uses struct tm need to be
>>> rebuild when moved from VMS 7.3-2 to 8.3 !
>>>
>>> Very non-VMSish !
>>>
>> 
>> Blame the C standards committee, not the OpenVMS developers.
>
>It is fully within the power of the VMS C developers to make a
>mismatch prevent a successful Link or Run command, rather than
>bombing strangely in the middle of operations.

^^
@@  What an eye popping idea!


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

http://tmesis.com/drat.html
0
VAXman
1/24/2008 8:00:31 PM
In article <XuzEANaHcesx@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <fnaf6e$shq$1@south.jnrs.ja.net>, "Richard Brodie" 
> <R.Brodie@rl.ac.uk> writes:
> > 
> > "yyyc186" <yyyc186@hughes.net> wrote in message 
> > news:4a1eb22e-94ac-4dc0-b6f5-39aaf3ea0003@k39g2000hsf.googlegroups.com...
> > 
> >> Until the ANSI C committee comes together, you can't "legally" fix the
> >> 2038 bug.  I'm sure they will get around to it in 2036 or so.

Since fixed and as yet unfixed implementations could easily be in full 
compliance with the relevant standards, I don't think the standard has 
anything to do with it.

> > Nothing in the C standard says that time_t is a 32-bit type.
> > No reason (apart from compatibility) not to promote it to 64-bits
> > today. Of course, you're out of luck on a VAX but nobody cares
> > about them, right? 
> 
>    Does anything say time_t is signed?

The C standard just says that it is a numeric type capable of 
representing times.  POSIX just says it is an arithmetic type "of an 
appropriate length" but also mentions that it is to be used for storing 
time in seconds.  I can't find anything that even says it has to be an 
integer nor that the number of seconds has to be since 1/1/1970.  As 
far as complying with the standard, time_t could be a 128-bit floating 
point number or even decimal for the storage hogs.

The problem is not in complying with the standard -- if anything that's 
too easy -- but rather in changing existing implementations in a way 
that will not break existing interfaces and applications and 
compatibility with existing data in permanent storage.

-- 
Posted via a free Usenet account from http://www.teranews.com

0
craigberry (308)
1/24/2008 8:40:58 PM
On Thu, 24 Jan 2008 11:29:54 -0800, Richard B. Gilbert  
<rgilbert88@comcast.net> wrote:

> Bob Koehler wrote:
>> In article <4798C5D6.4020701@comcast.net>, "Richard B. Gilbert"  
>> <rgilbert88@comcast.net> writes:
>>
>>> ISTR that the VAX instruction set had provisions for doing multiword  
>>> arithmetic if not actual 64 bit ADD, SUBTRACT, MULTIPLY and DIVIDE  
>>> instructions.  IOW it was not terribly difficult to do 64, 96 or 128  
>>> bit arithmetic if you REALLY needed it.
>>      Had it, used it, enjoyed it.  But the VAX C and DEC C compilers for
>>    VAX won't use them for you.
>>
>
> If you need these operations, you can "roll your own" in Macro and  
> access them from C.  They might even be in a library somewhere. I've  
> never needed to use integers that large.  I don't expect ever to need to.
>
Or just do it in PL/I up to 31 digits


-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
1/24/2008 10:30:11 PM
In article <XuzEANaHcesx@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <fnaf6e$shq$1@south.jnrs.ja.net>, "Richard Brodie" <R.Brodie@rl.ac.uk> writes:
>> 
>> "yyyc186" <yyyc186@hughes.net> wrote in message 
>> news:4a1eb22e-94ac-4dc0-b6f5-39aaf3ea0003@k39g2000hsf.googlegroups.com...
>> 
>>> Until the ANSI C committee comes together, you can't "legally" fix the
>>> 2038 bug.  I'm sure they will get around to it in 2036 or so.
>> 
>> Nothing in the C standard says that time_t is a 32-bit type.
>> No reason (apart from compatibility) not to promote it to 64-bits
>> today. Of course, you're out of luck on a VAX but nobody cares
>> about them, right? 
> 
>    Does anything say time_t is signed?

Considering that time_t is part of the OSes that use C and not part of the
language I really fail to see what the ANSI C Committee has to do with it
in the first place.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
1/24/2008 11:29:15 PM
In article <4798E732.3070107@comcast.net>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> Bob Koehler wrote:
>> In article <4798C5D6.4020701@comcast.net>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>>>ISTR that the VAX instruction set had provisions for doing multiword 
>>>arithmetic if not actual 64 bit ADD, SUBTRACT, MULTIPLY and DIVIDE 
>>>instructions.  IOW it was not terribly difficult to do 64, 96 or 128 bit 
>>>arithmetic if you REALLY needed it.
>> 
>> 
>>    Had it, used it, enjoyed it.  But the VAX C and DEC C compilers for
>>    VAX won't use them for you.
>> 
> 
> If you need these operations, you can "roll your own" in Macro and 
> access them from C.  They might even be in a library somewhere. I've 
> never needed to use integers that large.  I don't expect ever to need to.

LIB$ADDX and LIB$SUBX provide support for extended precisision integer
addition and subtraction on hardware that may or may not have
add-with-carry opcodes.

LIB$EMUL and LIB$EDIV emulate the EMUL and EDIV opcodes.
0
briggs3 (574)
1/25/2008 12:29:26 PM
In article <4798E732.3070107@comcast.net>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> If you need these operations, you can "roll your own" in Macro and 
> access them from C.  They might even be in a library somewhere. I've 
> never needed to use integers that large.  I don't expect ever to need to.
> 

   These VAX instructions are accessable to all languages as LIB$
   calls, which of course even work if your not on a VAX.

0
koehler2 (8314)
1/25/2008 1:47:50 PM
In article <5vslabF1o0n7dU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> Considering that time_t is part of the OSes that use C and not part of the
> language I really fail to see what the ANSI C Committee has to do with it
> in the first place.

   Aren't the routines that use time_t in thier API part of the ANSI
   standard C library?

0
koehler2 (8314)
1/25/2008 1:49:38 PM
In article <CWRXdbTdpIVK@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <5vslabF1o0n7dU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 
>> Considering that time_t is part of the OSes that use C and not part of the
>> language I really fail to see what the ANSI C Committee has to do with it
>> in the first place.
> 
>    Aren't the routines that use time_t in thier API part of the ANSI
>    standard C library?

God only knows what the ANSI Committee says but if it ain't in the compiler
it ain't part of the language.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
1/25/2008 2:59:22 PM
On Fri, 25 Jan 2008 06:59:22 -0800, Bill Gunshannon <billg999@cs.uofs.edu>  
wrote:

> In article <CWRXdbTdpIVK@eisner.encompasserve.org>,
> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <5vslabF1o0n7dU2@mid.individual.net>, billg999@cs.uofs.edu  
>> (Bill Gunshannon) writes:
>>>
>>> Considering that time_t is part of the OSes that use C and not part of  
>>> the
>>> language I really fail to see what the ANSI C Committee has to do with  
>>> it
>>> in the first place.
>>
>>    Aren't the routines that use time_t in thier API part of the ANSI
>>    standard C library?
>
> God only knows what the ANSI Committee says but if it ain't in the  
> compiler
> it ain't part of the language.

Well that is one of the fundamental flaws in the C design, it consists of  
two
separate parts, a compiler and a runtime, and as a result no semantic  
analysis
of the runtime routines at compile time.  Of course most of the routines  
should
not be part of the language anyway and are simply a carryover from OS  
(i.e.,
Unix) calls.

>
> bill
>



-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
1/25/2008 3:26:08 PM
In article <op.t5hrtu1mhv4qyg@murphus.hsd1.ca.comcast.net>,
	"Tom Linden" <tom@kednos.company> writes:
> On Fri, 25 Jan 2008 06:59:22 -0800, Bill Gunshannon <billg999@cs.uofs.edu>  
> wrote:
> 
>> In article <CWRXdbTdpIVK@eisner.encompasserve.org>,
>> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>> In article <5vslabF1o0n7dU2@mid.individual.net>, billg999@cs.uofs.edu  
>>> (Bill Gunshannon) writes:
>>>>
>>>> Considering that time_t is part of the OSes that use C and not part of  
>>>> the
>>>> language I really fail to see what the ANSI C Committee has to do with  
>>>> it
>>>> in the first place.
>>>
>>>    Aren't the routines that use time_t in thier API part of the ANSI
>>>    standard C library?
>>
>> God only knows what the ANSI Committee says but if it ain't in the  
>> compiler
>> it ain't part of the language.
> 
> Well that is one of the fundamental flaws in the C design, it consists of  
> two
> separate parts, a compiler and a runtime, and as a result no semantic  
> analysis
> of the runtime routines at compile time.  

And does Fortran do semantic analysis of NAGLIB?

>                                           Of course most of the routines  
> should
> not be part of the language anyway and are simply a carryover from OS  
> (i.e., Unix) calls.

They aren't part of the language but in an effort to blame all their
shortcomings on the language people have tied this into the language.

The language is what the compiler does.  Everything else is OS support
and has nothing to do with the language.  If you don't like the support
libraries write your own.  It won't affect the compiler one bit and will
not change the language.  (Hint:  I have a C compiler for my PDP-11 that
has no libraries as a part of the system.  It compile the language and
nothing more.  If I want printf() I have to implement it myself.  I have
the source for a Pascal compiler I am working on porting to the PDP-11
as well and guess what, it doesn't have any support routines either.
Just the language!)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
1/25/2008 3:45:15 PM
On Fri, 25 Jan 2008 07:45:15 -0800, Bill Gunshannon <billg999@cs.uofs.edu>  
wrote:

> In article <op.t5hrtu1mhv4qyg@murphus.hsd1.ca.comcast.net>,
> 	"Tom Linden" <tom@kednos.company> writes:
>> On Fri, 25 Jan 2008 06:59:22 -0800, Bill Gunshannon  
>> <billg999@cs.uofs.edu>
>> wrote:
>>
>>> In article <CWRXdbTdpIVK@eisner.encompasserve.org>,
>>> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>> In article <5vslabF1o0n7dU2@mid.individual.net>, billg999@cs.uofs.edu
>>>> (Bill Gunshannon) writes:
>>>>>
>>>>> Considering that time_t is part of the OSes that use C and not part  
>>>>> of
>>>>> the
>>>>> language I really fail to see what the ANSI C Committee has to do  
>>>>> with
>>>>> it
>>>>> in the first place.
>>>>
>>>>    Aren't the routines that use time_t in thier API part of the ANSI
>>>>    standard C library?
>>>
>>> God only knows what the ANSI Committee says but if it ain't in the
>>> compiler
>>> it ain't part of the language.
>>
>> Well that is one of the fundamental flaws in the C design, it consists  
>> of
>> two
>> separate parts, a compiler and a runtime, and as a result no semantic
>> analysis
>> of the runtime routines at compile time.
>
> And does Fortran do semantic analysis of NAGLIB?
>
>>                                           Of course most of the routines
>> should
>> not be part of the language anyway and are simply a carryover from OS
>> (i.e., Unix) calls.
>
> They aren't part of the language but in an effort to blame all their
> shortcomings on the language people have tied this into the language.
>
> The language is what the compiler does.  Everything else is OS support
> and has nothing to do with the language.  If you don't like the support
> libraries write your own.  It won't affect the compiler one bit and will
> not change the language.  (Hint:  I have a C compiler for my PDP-11 that
> has no libraries as a part of the system.  It compile the language and
> nothing more.  If I want printf() I have to implement it myself.  I have
> the source for a Pascal compiler I am working on porting to the PDP-11
> as well and guess what, it doesn't have any support routines either.
> Just the language!)
>

You missed the point was trying (apparently not so well) to make and that
is that primitive languages like C don't have a lot of builtin functions so
that sort of functionality, which might have been better as a part of the
language, gets shoved off to runtime, and so it gets lumped with other
routines such as OS calls.  Now in the case of OpenVMS, if disciplined
adherence to the use of SDL and Starlet had been maintained then you would
get semantic analysis of those routines, at least to the extent that the
specific language processor did that.  Of course, that by itself would not
have obviated the error incurred by Brian, but it might have helped catch  
it
in engineering, before release to the wild.

> bill
>



-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
1/25/2008 7:50:08 PM
In article <CWRXdbTdpIVK@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <5vslabF1o0n7dU2@mid.individual.net>, billg999@cs.uofs.edu (Bill 
> Gunshannon) writes:
> > 
> > Considering that time_t is part of the OSes that use C and not part of the
> > language I really fail to see what the ANSI C Committee has to do with it
> > in the first place.
> 
>    Aren't the routines that use time_t in thier API part of the ANSI
>    standard C library?

Yes, the routines that use time_t are part of the standard library and 
thus part of the C language.  However, as I posted earlier, the 
standards just say it's a numeric representing seconds; they don't say 
what kind of numeric type and they don't say seconds since when.  The 
fact that it's typically a 32-bit signed integer representing seconds 
since 1-jan-1970, however, does most likely derive from the system 
interfaces to various UNIX systems.

-- 
Posted via a free Usenet account from http://www.teranews.com

0
craigberry (308)
1/25/2008 8:35:06 PM
In article <5vubqaF1otlrsU3@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> God only knows what the ANSI Committee says but if it ain't in the compiler
> it ain't part of the language.
> 

   ANSI says the standard C library is part of the language.  Don't
   blame any poor gods for this.

0
koehler2 (8314)
1/28/2008 10:22:21 PM
In article <5vuegbF1o60phU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> The language is what the compiler does.  Everything else is OS support
> and has nothing to do with the language.  If you don't like the support
> libraries write your own.  It won't affect the compiler one bit and will
> not change the language.  (Hint:  I have a C compiler for my PDP-11 that
> has no libraries as a part of the system.  It compile the language and
> nothing more.  If I want printf() I have to implement it myself.  I have
> the source for a Pascal compiler I am working on porting to the PDP-11
> as well and guess what, it doesn't have any support routines either.
> Just the language!)

   Going all they way back to the original report on the Pascal language
   by it's inventors, there were two support routines included in the
   standard.

   And carying over UNIX OS specific routines like read() into another
   OS' support library for C to deal with the praticality of some much
   code which uses them is not the same as carrying over C standard 
   routines like printf() which have been given the honor of being
   part of the language be the folks selected to decide what the
   language is, whether the rest of us like thier decision or not.

0
koehler2 (8314)
1/28/2008 10:29:39 PM
Tom Linden wrote:
(snip)

> Well that is one of the fundamental flaws in the C design, 
> it consists of  two separate parts, a compiler and a runtime,
 > and as a result no semantic analysis of the runtime routines
 > at compile time.  Of course most of the  routines  should
> not be part of the language anyway and are simply a carryover
 > from OS  (i.e., Unix) calls.

Many of the library routine names are reserved, such that the
compiler is allowed to inline them.  For example, all names
starting with str are reserved.  If you write a user function
with a name starting with str it will be non-standard.

I don't know the exact separation, but most of the unix calls
are not part of the C library.  Many implement them for
compatibility reasons, though.  I usually assume that unix man 3
routines are C library and man 2 are unix, though the separation
may not be exactly right.

-- glen

0
gah (12851)
2/6/2008 8:09:51 PM
In article <IfudnTDgs6J9jzfanZ2dnUVZ_gmdnZ2d@comcast.com>,
	glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tom Linden wrote:
> (snip)
> 
>> Well that is one of the fundamental flaws in the C design, 
>> it consists of  two separate parts, a compiler and a runtime,
> > and as a result no semantic analysis of the runtime routines
> > at compile time.  Of course most of the  routines  should
>> not be part of the language anyway and are simply a carryover
> > from OS  (i.e., Unix) calls.
> 
> Many of the library routine names are reserved, such that the
> compiler is allowed to inline them.  For example, all names
> starting with str are reserved.  If you write a user function
> with a name starting with str it will be non-standard.
> 
> I don't know the exact separation, but most of the unix calls
> are not part of the C library.  

They would be on a unix machine.  :-)

>                                  Many implement them for
> compatibility reasons, though.  I usually assume that unix man 3
> routines are C library and man 2 are unix, 

Which would be wrong.

>                                             though the separation
> may not be exactly right.

Easy enough to find out, ask "man"!

$ man 2 intro
INTRO(2)                  FreeBSD System Calls Manual                 INTRO(2)

NAME
     intro -- introduction to system calls and error numbers

LIBRARY
     Standard C Library (libc, -lc)

............

$ man 3 intro
INTRO(3)               FreeBSD Library Functions Manual               INTRO(3)

NAME
     intro -- introduction to the C libraries

DESCRIPTION
     This section provides an overview of the C library functions, their error
     returns and other common definitions and concepts.  Most of these func-
     tions are available from the C library, libc.  Other libraries, such as
     the math library, libm, must be indicated at compile time with the -l
     option of the compiler.

     The various libraries (followed by the loader flag):

     libc (-lc)  Standard C library functions.

     libcurses (-lcurses -ltermcap) Terminal independent screen management
                                     routines

     libcompat (-lcompat) Functions which are obsolete but are available
                          for compatibility with 4.3BSD.

     libkvm (-lkvm) Functions used to access kernel memory

     libl (-ll)  The library for lex(1).

     libm (-lm)  The math library, libm.  The math library is loaded as needed

     libmp (-lmp)

     libtermcap (-ltermcap)
                 The terminal independent operation library package.  (See
                 termcap(3).)

     liby (-ly)  The library for yacc(1).

....................

Edited of some verbage.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
2/7/2008 2:24:12 PM
In article <610ikbF1su041U2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> In article <IfudnTDgs6J9jzfanZ2dnUVZ_gmdnZ2d@comcast.com>,
> 	glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>                                  Many implement them for
>> compatibility reasons, though.  I usually assume that unix man 3
>> routines are C library and man 2 are unix, 
> 
> Which would be wrong.

   Just because the file libc.a contains the entry points used to get
   into the system routines, does not make them part of the standard C
   library.  The ANSI C committee gets to define the standard C library.

   According to POSIX, there are mutiple langauge interfaces defined to
   the system routines on any POSIX compliant UNIX.  The entry points for
   each language might be in that langauges' library file, but that 
   doesn't prevent them from being part of UNIX rather than the language.

   The text you quoted from the man pages clearly shows that 2 is
   system calls and 3 is C libraries, even though the entry points are
   both in libc.a for the C language:


> INTRO(2)                  FreeBSD System Calls Manual                 INTRO(2)
> 
> NAME
>      intro -- introduction to system calls and error numbers
                                ^^^^^^^^^^^^

> INTRO(3)               FreeBSD Library Functions Manual               INTRO(3)
> 
> NAME
>      intro -- introduction to the C libraries
                                    ^^^^^^^^^^^
0
koehler2 (8314)
2/7/2008 6:09:14 PM
In article <GU9GvEoLE0T4@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <610ikbF1su041U2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> In article <IfudnTDgs6J9jzfanZ2dnUVZ_gmdnZ2d@comcast.com>,
>> 	glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>                                  Many implement them for
>>> compatibility reasons, though.  I usually assume that unix man 3
>>> routines are C library and man 2 are unix, 
>> 
>> Which would be wrong.
> 
>    Just because the file libc.a contains the entry points used to get
>    into the system routines, does not make them part of the standard C
>    library.  The ANSI C committee gets to define the standard C library.

Well, the ANSI C committee gets to decide what they're going to call "ANSI C".
But that's about as far as it goes. 
 
> 
>    According to POSIX, there are mutiple langauge interfaces defined to
>    the system routines on any POSIX compliant UNIX.  The entry points for
>    each language might be in that langauges' library file, but that 
>    doesn't prevent them from being part of UNIX rather than the language.
> 
>    The text you quoted from the man pages clearly shows that 2 is
>    system calls and 3 is C libraries, even though the entry points are
>    both in libc.a for the C language:


Right, that was my point but you cut some of the relevant parts.

The original statements were:

    "most of the unix calls are not part of the C library."

> 
> 
>> INTRO(2)                  FreeBSD System Calls Manual                 INTRO(2)
>> 
>> NAME
>>      intro -- introduction to system calls and error numbers
>                                 ^^^^^^^^^^^^

You cut:

LIBRARY
     Standard C Library (libc, -lc)

So they are in the "Standard C Library".

> 
>> INTRO(3)               FreeBSD Library Functions Manual               INTRO(3)
>> 
>> NAME
>>      intro -- introduction to the C libraries
>                                     ^^^^^^^^^^^

The original poster had said: 

    "I usually assume that unix man 3 routines are C library and man 2
     are unix, though the separation may not be exactly right."

I posted the relevant parts that tell exactly what is in man section
2 and man section 3 which, hopefully, clarified for him just what is
in each man section.

What section of the man pages contains what information was decided on
a long time ago.  There is no ambiguity.  All one has to do is read the
relevant information.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
2/7/2008 6:20:48 PM
In article <6110g0F1q9jdfU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> Right, that was my point but you cut some of the relevant parts.
> 

   The relavent parts that I cut were the onse that pointed out that
   the entries were in libc.a, which I acknowledged, but doens't prove
   your point.

0
koehler2 (8314)
2/8/2008 1:20:12 PM
Reply:

Similar Artilces:

Calling 'foo.c' or 'foo2.c' from my 'main_code.c'
Hello. I don't know if following is possible. I've got 'main_code.c': ............................ char * another_code; another_code = "foo.c"; ............................ I've got 'foo.c': ............................ #include <stdio.h> int main() { printf ("Hello world from 'foo.c'!\n"); return 0; } ............................ I would like to call 'foo.c' main function from 'main_code.c'. Is this possible? Thank you very much and best regards. Francesco Moi <francescomoi@europe.com> scribbled the ...

if ('A:B:C' =~ /:(.*?)$/) then why the heck is $1 'B:C' and not just 'C'
To repeat the title, in case it is munged by Google Groups: if ('A:B:C' =~ /:(.*?)$/) then why the heck is $1 'B:C' and not just 'C' I've been developing with perl for years; but even simple things in it still sometimes throw up surprises. The regexp /:(.*?)$/ is anchored on the right by $, then comes a non- greedy match which, AIUI, is the "shortest string it can get away with", preceded by a colon. So I would expect this to pick up just the "C", as it does with /([^:]*)$/. Am I assuming/doing something silly? It is frid...

{ '0':'c->c->a' ,'1':'a->b->a' .........}
Hi, have anybody a hint , how i get a dict from non unique id's and their different related values. Thanks for advance Chris ###random data # a=range(10)*3 def seqelem(): i=random.randint(0,2) elem=['a','b','c'][i] return elem s=[seqelem() for t in range(30)] print zip(a,s) ## favored result: { '0':'c->c->a' ,'1':'a->b->a' .........} Hi Chris, I may have time to look at the rest of your code later. For now I just want to comment on one line: On Nov 7, 12:24=A0pm, chris <o...

'^=' and '~='?
Hello, What is the difference between '^=' and '~='? Thanks, Duckhye ...

'is not' or '!='
A newbie question to you; what is the difference between statements like: if x is not None: and if x != None: Without any context, which one should be preferred? IMHO, the latter is more readable. On 2014-08-18 21:35, ElChino wrote: > A newbie question to you; what is the difference between statements > like: > if x is not None: > and > if x != None: > > Without any context, which one should be preferred? > IMHO, the latter is more readable. > "x == y" tells you whether x and y refer to objects that are equal. "x is y&qu...

'ab\c' and 'ab\\c'
I encountered a rather peculiar behavior of strings today. Here is my irb session: ------------------------------------------------------------------- irb(main):001:0> 'ab\c' irb(main):002:0' ' SyntaxError: compile error (irb):2: unterminated string meets end of file from (irb):2 irb(main):003:0> 'ab\\c' => "ab\\c" irb(main):004:0> 'a\b' => "a\\b" irb(main):005:0> ------------------------------------------------------------------- As you can see when I typed 'ab\c' my irb didn't return. It was expecting...

a regexp riddle: re.search(r'(?:(\w+), |and (\w+))+', 'whatever a, bbb, and c') =? ('a', 'bbb', 'c')
HypoNt: I need to turn a human-readable list into a list(): print re.search(r'(?:(\w+), |and (\w+))+', 'whatever a, bbb, and c').groups() That currently returns ('c',). I'm trying to match "any word \w+ followed by a comma, or a final word preceded by and." The match returns 'a, bbb, and c', but the groups return ('bbb', 'c'). What do I type for .groups() to also get the 'a'? Please go easy on me (and no RTFM!), because I have only been using regular expressions for about 20 years... -- Phlip h...

RE: Obsucure Inquier article about Intel mentions VMS (and not any other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other
> -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 > Sent: October 11, 2004 11:45 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Obsucure Inquier article about Intel mentions=20 > VMS (and not any other OS') other OS') other OS') other OS')=20 > other OS') other OS') other OS') other OS') other OS') other=20 > OS') other OS') other OS') other OS') other OS') other OS') other=20 >=20 > "Main, Kerry" wrote: > > Course, there are many ways to offer differen...

RE: Obsucure Inquier article about Intel mentions VMS (and not any other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS')
> -----Original Message----- > From: Soterro [mailto:soterroatyahoocom@address.hp.com]=20 > Sent: October 11, 2004 9:43 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Obsucure Inquier article about Intel mentions=20 > VMS (and not any other OS') other OS') other OS') other OS')=20 > other OS') other OS') other OS') other OS') other OS') >=20 > Main, Kerry wrote: > >>From: John Smith [mailto:a@nonymous.com]=20 > >>You aren't directly to blame for this and I know you'd like=20 > >>to keep your > &...

'''''''''''''The Running Update/Append Queries Using VBA code Ordeal''''''''''''''
Hello fellow programmers, I am trying to run an append/update query from code, a command button on a form initiates the queries. the format i am using is; _____________________________________________________ SELECT "criteria" FROM "criteria" WHERE "criteria" UPDATE/APPEND "field selections" RecordSource "qryExample" = above text strings" _______________________________________________________________________ When i am running a SELECT query in this manner it works fine with no problems, and accepts the values of specified linked for...

difference between 'C++ Primer' and 'C++ Primer Plus'
Hi, Can someone tell me whats the difference between the books (1) C++ Primer, 3rd ed (1998) by Stanley B Lippman & Josee Lajoie and (2) C++ Primer Plus (2001) By Stephen Prata (3) Waite Group C++ Primer Plus (1998) By Snaith All seem to get excellent reviews on www.accu.org and comp.lang.c++.*. Is (2) just the next edition of (1). If there is little difference I would like to get (1) as there is an answer book available: C++ Primer Answer Book (Visual QuickStart Guide), (1999) By Clovis L. Tondo, Bruce P. Leung Thanks to every body in advance :-) [ See http://ww...

Is there a simple function to generate a list like ['a', 'b', 'c', ... 'z']?
Is there a simple function to generate a list like ['a', 'b', 'c', ... 'z']? The range() just can generate the numeric list. On Apr 9, 2007, at 3:29 AM, =E4=BA=BA=E8=A8=80=E8=90=BD=E6=97=A5=E6=98=AF=E5= =A4=A9=E6=B6=AF=EF=BC=8C=E6=9C=9B=E6=9E=81=E5=A4=A9=E6=B6=AF=E4=B8=8D=20 =E8=A7=81=E5=AE=B6 wrote: > Is there a simple function to generate a list like ['a', 'b', 'c', ... > 'z']? The range() just can generate the numeric list. import string list(string.lowercase) 人言落日是天涯,望极天涯不见家 schrieb: > Is there a simple ...

What does 'c' in 'cout' mean?
Hi, I'm wondering what 'c' in "cout", "cin" mean? Does it mean "C++"? Or the 'c' in <cassert>? Thanks, Peng On 10 19 , 9 13 , "PengYu...@gmail.com" <PengYu...@gmail.com> wrote: > Hi, > > I'm wondering what 'c' in "cout", "cin" mean? Does it mean "C++"? Or > the 'c' in <cassert>? > http://www.research.att.com/~bs/bs_faq2.html#cout "PengYu.UT@gmail.com" <PengYu.UT@gmail.com> wrote: > Hi, > > I'm wondering what 'c...

'''''''''''''The Running Update/Append Queries Using VBA code Ordeal'''''''''''''' #2
Hi, Thanks for ur help there HJ. I know how to do the tasks you specified there. I would like for the update query to use field values from some of the fields on the form (frmInvoices) such as InvoiceNumber, DateFrom, DateTo. My problem is that an append/update query can't find the values in the open Form (frmInvoices) when I specify them as; [Forms]![frmInvoices]![InvoiceNumber] a select query has no problem finding the field values on a form. please help. Aaron Hi Aaron, Could you post the entire code that you are having trouble with? Now it is not possible to see what goes wron...

if str_mo not in ('','.') and str_da not in ('','.') and str_yy not in ('','.') Any shorter ?
Hi, there. =20 I'm just curious if it ever dawned on anybody how to abbreviate this line : if str_mo not in ('','.') and str_da not in ('','.') and str_yy not in ('','.')=20 =20 Igor Kurbeko Clinical Programmer Analyst 678 336 4328 ikurbeko@atherogenics.com =20 no brain no pain =20 how about: if not (str_mo in ('','.') or str_da in ('','.') or str_yy in ('','.')) OR if not (missing(str_mo) or missing(str_da) or missing(str_yy)) Eric On 22 Oct 03 21:13:37 GMT, ikurbeko@ATHER...

how to make ["a","b",["c","d"],"e"] into ['a', 'b', 'c', 'd', 'e'] ?
--001a11c34e8edbc7c404f6a94bbe Content-Type: text/plain; charset=ISO-8859-1 >>> x=["a","b",["c","d"],"e"] >>> y=x[2] >>> y ['c', 'd'] >>> x.insert(2,y[0]) >>> x ['a', 'b', 'c', ['c', 'd'], 'e'] >>> x.insert(3,y[1]) >>> x ['a', 'b', 'c', 'd', ['c', 'd'], 'e'] >>> del x[4] >>> x ['a', 'b', 'c', 'd', &#...

Corectly convert from %PATH%=c:\\X;"c:\\a;b" TO ['c:\\X', 'c:\\a;b']
Hi, I am trying to treat an environment variable as a python list - and I'm sure there must be a standard and simple way to do so. I know that the interpreter itself must use it (to process $PATH / %PATH%, etc) but I am not able to find a simple function to do so. os.environ['PATH'].split(os.sep) is wrong on Windows for the case when PATH="c:\\A;B";c:\\D; where there is a ';' embedded in the quoted path. Does anyone know of a simple way (addons ok) which would do it in a cross platform way? If not - I will roll my own. My search has shown that generally people ...

A function with 'and' , 'not' , 'null' , 'car' and 'cdr'
What's this ? (defun enigma (x) (and (not (null x)) (or (null (car x)) (enigma (cdr x))))) "I suppose I should learn Lisp, but it seems so foreign." - Paul Graham, Nov 1983 On Wed, Oct 07 2015, CAI GENGYANG wrote: > What's this ? > > > (defun enigma (x) > (and (not (null x)) > (or (null (car x)) > (enigma (cdr x))))) Bad taste? It returns T if the list X contains nil as an element. It would be clearer to write (some #'null x). Helmut CAI GENGYANG ...

Re: if str_mo not in ('','.') and str_da not in ('','.') and str_yy not in ('','.') Any shorter ?
OR you could use ARRAY data new; set old; array igor $ (*) str_mo str_da str_yr; do over igor; if igor ~in (' ','.') then do; end; run; Prasad Ravi Igor Kurbeko <ikurbeko@ATHEROGENIC To: SAS-L@LISTSERV.UGA.EDU S.COM> cc: Sent by: "SAS(r) Subject: if str_mo not in ('','.') and str_da not in ('','.') and str_yy ...

A question about '=='' in C++!
Can anyone tell me the different between (1) int i, j; i = j ==1; cout << i; cout << j; and (2) int i, j; i = j = 1; cout << i; cout << j; Why the result of (1) is 0 0 while the result of (2) is 1 1 Thanks! -- comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry. Guofu Chen wrote: > Can anyone tell me the different between > (1) > int i, j; > i = j...

error: expected '=', ',', ';', 'asm' or '__attrib
Hi I'm trying to compile an ADC Driver & come acrosss the following error. I've no experience writing drivers before, and hence have no clue how to fix it. Hope someone out there has encountered the problem & suggesst a fix for the same. The Error is I get is : qadc.c: At top level: qadc.c:97: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'qadc_read' make: *** [qadc.o] Error 1 [root@localhost qadc]# ########################################################################### ADC Driver Code ####################...

error: expected '=', ',', ';', 'asm' or '__attrib
Hi I'm trying to compile an ADC Driver & come acrosss the following error. I've no experience writing drivers before, and hence have no clue how to fix it. Hope someone out there has encountered the problem & suggesst a fix for the same. The Error is I get is : qadc.c: At top level: qadc.c:97: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'qadc_read' make: *** [qadc.o] Error 1 [root@localhost qadc]# ########################################################################### ADC Driver Code ##...

wxIE doesn't handle 'enter', 'delete' key, 'control-c' 'control-v' properly
I built the wxIE project from: http://sourceforge.net/projects/wxactivex Which is great, but I can't use the 'delete' key, nor 'enter', nor control-c/control-v in the IE window. Using SPY++ and stepping through the code I see that the keys are being sent to the IE Window so I'm lost as to how to make it work. Has anyone seen oddities like this using wxActiveX? Everything looks right so it's very frustrating... Joe -- View this message in context: http://www.nabble.com/wxIE-doesn%27t-handle-%27enter%27%2C-%27delete%27-key%2C-%27control-c%27-%27co...

'[OFF]' as in 'offensive'???
Hi, given that 'off-topicness' is indicated as '[OT]' and taking a look at those postings that started the threads indicated as '[OFF]' (which may both be seen as being somewhat offensive) may lead to the conclusion that '[OFF]' stands for offensiveness. I don't think that this is the intended meaning so what actually *does* '[OFF]' mean? I never came across that abbreviation before (although I have been around on the USENET for quite some time) but maybe it is worth knowing? Josef 'Jupp' Schugt NOTE: mails >100 KiB ...

Web resources about - To 'C' or not to 'C' ... now what the hell to I do? - comp.os.vms

Resources last updated: 2/15/2016 4:41:07 AM