HDTenEightyP/NetNews huggingface dataset:
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Struct hack one last time (one last time)
Summary: Claim of circular reasoning disproved
Organization: SoftQuad Inc., Toronto, Canada
Date: Sat, 9 Jan 93 04:27:41 GMT

I said:
| In particular, it could not modify padding at the end of a struct,
| precisely *because* it would break the struct hack.

Steve Clamage replied:
> We seem to have some circular reasoning here.
> I proposed an implemention which I claimed was conforming on which
> the struct hack would not work; therefore the struct hack is illegal.
> Mark claims the struct hack is legal; therefore the proposed
> implementation is not conforming.

My reasoning only looks circular if you do not consider that statement
"the struct hack is conforming" has *already* been proven.  My actual
claim, or rather statement, is that it has been.  And since this *is*
established, we can then make other deductions from it, such as that
Steve's proposed implementation is non-conforming.  (As it happens, this
has also been proved on other grounds in other postings.)
-- 
Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
  "And just when I had you wriggling in the crushing grip of reason, too."
   -- Calvin and Hobbes
      (borrowed just for the occasion from a colleague's signature collection)
 
This article is in the public domain.
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Struct hack one last time (one last time)
Date: 11 Jan 93 16:34:19 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1993Jan8.184304.10965@taumet.com>, steve@taumet.com (Steve Clamage) writes:
|> You could subvert this via void* pointers, but that isn't the point.
|> Presumably this is an optional checkout mode, and such modes typically
|> impose constraints on programmers.  If you play games to subvert type
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thus throwing the implementation into a non-conforming state, which was
the whole point of this discussion.

|> checking, you are going to have problems.
|> -- 
|> 
|> Steve Clamage, TauMetric Corp, steve@taumet.com

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Struct hack one last time (one last time)
Organization: TauMetric Corporation
Date: Fri, 8 Jan 1993 19:08:40 GMT

msb@sq.sq.com (Mark Brader) writes:

>In particular, it could not modify padding at the end of a struct,
>precisely *because* it would break the struct hack.

We seem to have some circular reasoning here.

I proposed an implemention which I claimed was conforming on which
the struct hack would not work; therefore the struct hack is illegal.

Mark claims the struct hack is legal; therefore the proposed
implementation is not conforming.

I think we need to show that the proposed implementation is non-
conforming or that the the struct hack is not strictly-conforming by
appealing to the language of the standard.

I remain unconvinced that the struct hack is strictly conforming,
completely apart from the possibly flakey implementation I proposed.

For example, if the struct hack is strictly conforming, what about this:

	struct S {
	    double a[2];
	    double b;
	} s;
	s.a[2] = 1.0;

The array reference exceeds the declared bounds of s.a, but not the
bounds of object s, because sizeof(s) can't be smaller than
sizeof(a)+sizeof(b).  If a compiler can't add padding to the end of
the struct for other than alignment, then surely it can't add padding
between a and b, because it can't be required for alignment.  Therefore
s.a[2] must be the same as s.b.

I don't buy this reasoning, and it seems to me it is no different
from the struct hack.  I claim that both this example and the
struct hack are not strictly conforming, because the declared bounds
of an array are exceeded.  Probably both examples will work on any
typical implementation, however, which is a separate issue.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c
From: steve@unidata.ucar.edu (Steve Emmerson)
Subject: understanding FLT_DIG
Organization: University Corporation for Atmospheric Research (UCAR)
Distribution: na
Date: Tue, 5 Jan 1993 23:06:51 GMT

Hi,

I'm having trouble understanding FLT_DIG, which is defined in <float.h>,
According to section 2.2.4.2.2 of the ANSI standard, FLT_DIG is given by
the following on base-2 machines:

	FLT_DIG = (int)((p-1)*log10(2))

where `p' is the precision (the number of base-2 digits in the
significand).

On a hypothetical base-2 machine with 4 bits of precision, the above yields
0 for FLT_DIG.  Yet, those 4 bits can represent the integral values 1
through 9 exactly.  Thus, shouldn't FLT_DIG be 1?

Eagerly awaiting enlightenment.
--

Steve Emmerson        steve@unidata.ucar.edu        ...!ncar!unidata!steve
From: heiniw@eebsun1.eeb.ele.tue.nl (Heini Withagen)
Newsgroups: comp.std.c
Subject: Problems with gcc/g++ and profiling
Date: 12 Jan 93 15:40:55 GMT
Organization: Electronic Circuit Design Group, Eindhoven University of Technology, The Netherlands



I am having trouble with gcc/g++ 2.2.2 compiling programs with -pg
options for profiling. I have been looking what g++ actually does
during compilation/linking (-v option) and compared this to 'cc' (on 
a SUN Sparc).

It seem that g++ is linking the wrong libraries which do not contain
the right function for profiling. When I try to make a seperate call
to the linker with the same libraries substituded as with 'cc', I get
a long list of 'Undefined' names which look like 'LBE??' and 'LBB??'.


Does anyone know the answer to my problems ?? Please help me, because
I am getting quite desperate.


Thanks very much in advance,

Heini Withagen
Department of Electrical Engineering EH 9.29
Eindhoven Technical University
P.O. Box 513
5600 MB Eindhoven
The Netherlands
Phone: 31-40472366
Fax:   31-40455674
E-mail: heiniw@eeb.ele.tue.nl
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: current time
Keywords: time, portable
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 5 Jan 1993 00:26:32 GMT

In article <1993Jan4.063302.8342@newshub.ccs.yorku.ca> s442016@nexus.yorku.ca (Alan Li) writes:
>   how does one get the current time with C?
>  I know about the functions in TIME.H, but they return
>  unreadable integers, well at least to me it is.

If you know about the functions in <time.h> then you know about asctime(),
ctime(), gmtime(), localtime(), and strftime().  What are you missing?
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
Newsgroups: comp.std.c,comp.std.internat,comp.lang.c
From: tork@convex.com (Bill Torkelson)
Subject: Re: Need ANSI / POSIX spec for C
Date: Wed, 6 Jan 1993 00:20:21 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Keywords: ansi posix iso/iec9899 iso/iec9945
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

maw@netcom.com (Martin Walker) writes:
>Can anyone tell me where I can get hold of the complete ANSI and POSIX
>standards for the C language? Any form is OK, although in electronic form
>is preferable. Please respond via email to maw@netcom.netcom.com.

You can order the C standard by sending $139.10 ($130 + 7% S&H) to:

	ANSI
	11 W 42nd Street
	New York New York 10036

The document you want is ANSI/ISO 9899-1990.


I just talked to them today, but I haven't sent my check yet.


--
Bill Torkelson
Convex Computer Corporation
phone: (214)497-4328 fax: (214)497-4500
email: tork@convex.com 
Newsgroups: comp.std.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Struct hack one last time (one last time)
Organization: Sequoia Peripherals, Inc.
Date: Thu, 7 Jan 93 22:12:07 GMT


Deleting most of the back and forth here, you know where to
find it if you need it.

>|> >>An implementation is allowed to add padding to the end of a struct.
>|> >>Suppose that the implementation adds space to the end of each struct
>|> >>type where it encodes information used for run-time error checking.

>How should the poor compiler know WHERE to insert that information.  For malloc
>there might be special handling in the compiler, but consider a library
>memory-allocation routine of my own that returns void * and which does not
>impose a simple relationship between arguments and the size of the
>chunk of memory allocated!

This has nothing to do with malloc. The hypothetical compiler
could simply insert this error checking information whenever
it does a conversion from a (void *) to a (struct foo *). Again,
the basic question is still unresolved here: can a conversion
from one pointer type to another affect bytes other than those
where the pointer variable is stored?


-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
Newsgroups: comp.std.c,comp.std.internat,comp.lang.c
From: jenkins@jpl-devvax.jpl.nasa.gov (Steve Jenkins)
Subject: Re: Need ANSI / POSIX spec for C
Summary: (800) 624-3974
Organization: Jet Propulsion Laboratory (NASA)
Date: Wed, 6 Jan 1993 23:02:29 GMT

In article <C0GCtu.Lw0@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>
>Often a more convenient source for such things is Global Engineering
>Documents, (714)261-1455.  For one thing, unlike ANSI, they take phone
>orders using credit cards.

They can also be reached at (800) 624-3974, at least in the U.S.

-- 
Steve Jenkins      			jenkins@devvax.jpl.nasa.gov
Caltech/Jet Propulsion Laboratory	(818) 306-6438
From: jlewis@indyvax.iupui.edu
Newsgroups: comp.std.c
Subject: ZMODEM ,YMODEM Source?
Date: 11 Jan 93 13:32:22 -0500

I'm looking for the source code to the ZModem communications protocol.  Does
anyone have any idea where I can find it?  Other protocols are also welcomed
but ZModem is most desired.

Thanks

Jeff

Newsgroups: comp.std.c
From: s442016@nexus.yorku.ca (Alan Li)
Subject: current time
Keywords: time, portable
Organization: York University, CS Dept. Toronto
Date: Mon, 4 Jan 1993 06:33:02 GMT


hi there

   how does one get the current time with C?
  I know about the functions in TIME.H, but they return
  unreadable integers, well at least to me it is.
  do I have to do some operations on these numbers or something????

                      ....newbie with C.....alan LI
From: tlp00@ras.amdahl.com (Tibor Polgar)
Newsgroups: comp.std.c
Subject: Protoize
Date: 11 Jan 93 23:16:03 GMT
Reply-To: tlp00@ras.amdahl.com
Organization: Amdahl Corporation, Sunnyvale CA

Anyone know where i can get a program called "protoize".   This filter is supposed
to generate function prototypes.  

Thanks.
-------------------------------------------------------------------------------
| Tibor L. Polgar    |  (408) 746-8649     | tlp00@climb.ras.amdahl.com
| Amdahl Corporation
| 1250 East Arques Avenue (M/S 281)
| P.O. Box 3470
| Sunnyvale, CA 94088-3470
------------------------------------------------------------------------------
Newsgroups: comp.std.c
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Struct hack one last time (one last time)
Date: 8 Jan 93 21:22:44 GMT

Struct hack several last times.

A simpler objection to Dave Eisen's scheme is to take the return value from a
malloc and cast it to pointers to two different struct types, stored in
different pointer variables, and then use them alternately just like a union.
The number of bytes malloced should be the max of the "sizeof"s of the two
struct types.

Chris Volpe's code which begins:
>struct foo {double field[2];} *fp;
>char bar[]="LongerThanSizeOfStructFoo";
>fp = (struct foo *)bar;
is already invalid because you can't cast "bar" to a struct type because of
alignment rules.  But you could malloc some memory, strcpy that string into it,
then cast it, which is kind of like my union-like example.

steve@taumet.com (Steve Clamage) writes:
>	struct S {
>	    double a[2];
>	    double b;
>	} s;
>	s.a[2] = 1.0;

and compares it to the struct hack.

This is completely different than the struct hack for two reasons.

This would only be similar to the struct hack if "s" were malloced, rather than
declared, and if the type of "a" were char.  Neither of these properties holds
in your example.  Both of these properties were crucial to some methods of
arguing the validity of the struct hack, and the second property is crucial to
all of them.

As well, the interpretation ruling about declaring an int[3][4] and accessing
a[0][7] applies to Mr Clamage's example, imho, so his quoted code is invalid.
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Struct hack one last time (one last time)
Organization: TauMetric Corporation
Date: Fri, 8 Jan 1993 18:43:04 GMT

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:

>steve@taumet.com (Steve Clamage) writes:
>>An implementation is allowed to add padding to the end of a struct.
>>Suppose that the implementation adds space to the end of each struct
>>type where it encodes information used for run-time error checking.

>Can't do that... what happens when you malloc one of them?

>	struct whatever *p = (struct whatever *)malloc(sizeof(struct whatever));

>Immediately after the malloc, if p is not null you can start using the struct,
>but it won't have that run-time-error-checking information, so it will fault.

The compiler is allowed to recognize calls to standard library functions.
It could fix up the returned struct after the call to malloc (or realloc
or calloc).  It would also have to interpret the size in case an array
were being allocated:
	extern size_t s;
	struct w *p = malloc(s);
	/* fixup s/sizeof(struct w) structs here */

You could subvert this via void* pointers, but that isn't the point.
Presumably this is an optional checkout mode, and such modes typically
impose constraints on programmers.  If you play games to subvert type
checking, you are going to have problems.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Struct hack one last time (one last time)
Date: 8 Jan 93 13:56:44 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1993Jan7.221207.13818@leland.Stanford.EDU>, dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
|> 
|> This has nothing to do with malloc. The hypothetical compiler
|> could simply insert this error checking information whenever
|> it does a conversion from a (void *) to a (struct foo *). Again,
|> the basic question is still unresolved here: can a conversion
|> from one pointer type to another affect bytes other than those
|> where the pointer variable is stored?

Of course not. What would happen in the following program?

	int main(void)
	{
	  struct foo {double field[2];} *fp;
	  char bar[]="LongerThanSizeOfStructFoo";
	  fp = (struct foo *)bar;
	  /* Does the above cast modify the contents of bar? */
	  if (strcmp(bar,"LongerThanSizeOfStructFoo"))
	    fprintf(stderr,"Dumb-ass compiler\n");
	  return 0;
	}

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.std.c
Subject: Re: Struct hack one last time (one last time)
Date: 11 Jan 93 10:28:42 GMT
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany

In article <1993Jan8.184304.10965@taumet.com> steve@taumet.com (Steve Clamage) writes:
[...]
:The compiler is allowed to recognize calls to standard library functions.
:It could fix up the returned struct after the call to malloc (or realloc
:or calloc).  It would also have to interpret the size in case an array
:were being allocated:
:	extern size_t s;
:	struct w *p = malloc(s);
:	/* fixup s/sizeof(struct w) structs here */
:
:You could subvert this via void* pointers, but that isn't the point.
:Presumably this is an optional checkout mode, and such modes typically
:impose constraints on programmers.  If you play games to subvert type
:checking, you are going to have problems.

Wait, wait, I think this argument is not quite fair.  I could proceed
along the same path claiming a conforming program should not use setjmp/
longjmp because I may envision some implementation which provides an
optional checkout mode for programs that avoid setjmp, etc, etc.
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
Newsgroups: comp.std.c,comp.std.internat,comp.lang.c
From: maw@netcom.com (Martin Walker)
Subject: Need ANSI / POSIX spec for C
Keywords: ansi posix iso/iec9899 iso/iec9945
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 5 Jan 1993 20:49:12 GMT


Hello all.

Can anyone tell me where I can get hold of the complete ANSI and POSIX
standards for the C language? Any form is OK, although in electronic form
is preferable. Please respond via email to maw@netcom.netcom.com.

Thanks in advance,
Kean Johnston, via
maw@netcom.netcom.com
-- 
Martin Walker               |  "One way to stop a runaway horse
++27-12-344-3973 (w)        |   is to bet on him"
++27-12-998-7263 (h)        |   maw@netcom.com
Pretoria, South Africa      |   martin@paradigm.CO.ZA
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.std.c
Subject: Re: Struct hack one last time (one last time)
Date: 9 Jan 93 20:22:06 GMT
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany

In article <1993Jan7.221207.13818@leland.Stanford.EDU> dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
[...]
>This has nothing to do with malloc. The hypothetical compiler
>could simply insert this error checking information whenever
>it does a conversion from a (void *) to a (struct foo *). Again,
>the basic question is still unresolved here: can a conversion
>from one pointer type to another affect bytes other than those
>where the pointer variable is stored?

Which directly brings up the question if (or if not) for
any modifiable lvalue `x' and some `y' of the same type an
assignment
			x = y;
may behave differently
as a bitwise copy
			memcpy(&x, &y, sizeof x);

(For the pedantics: Assume the appropriate header is included
and the two objects do not overlap.)

To put it into the language of the standard: May some (otherwise
strictly conforming) program change its behavior if the above
two were switched.
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
Newsgroups: comp.std.c
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Struct hack one last time (one last time)
Date: 7 Jan 93 19:51:17 GMT

steve@taumet.com (Steve Clamage) writes:
>An implementation is allowed to add padding to the end of a struct.
>Suppose that the implementation adds space to the end of each struct
>type where it encodes information used for run-time error checking.

Can't do that... what happens when you malloc one of them?

	struct whatever *p = (struct whatever *)malloc(sizeof(struct whatever));

Immediately after the malloc, if p is not null you can start using the struct,
but it won't have that run-time-error-checking information, so it will fault.
Newsgroups: comp.std.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Struct hack one last time (one last time)
Organization: Sequoia Peripherals, Inc.
Date: Thu, 7 Jan 93 20:08:13 GMT

In article <1993Jan7.145117.8220@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>steve@taumet.com (Steve Clamage) writes:
>>An implementation is allowed to add padding to the end of a struct.
>>Suppose that the implementation adds space to the end of each struct
>>type where it encodes information used for run-time error checking.
>
>Can't do that... what happens when you malloc one of them?
>
>	struct whatever *p = (struct whatever *)malloc(sizeof(struct whatever));
>
>Immediately after the malloc, if p is not null you can start using the struct,
>but it won't have that run-time-error-checking information, so it will fault.

I don't know whether or not implementations are allowed to
do what Steve is suggesting here, but I don't think this
is a reason why it couldn't. Couldn't the compiler, as part
of the code it emits to convert the (void *) returned by
malloc also emit instructions to set up the information that
Steve is postulating here? Or is there language in the the
standard that forbids a conversion from one pointer type to
another to affect the block of memory to which this pointer 
points?


-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
Newsgroups: comp.std.c
From: blume@kastle.Princeton.EDU (Matthias Blume)
Subject: Re: Struct hack one last time (one last time)
Reply-To: blume@kastle.Princeton.EDU (Matthias Blume)
Organization: Dept. of Computer Science, Princeton University
Date: Fri, 8 Jan 1993 15:32:13 GMT

In article <1993Jan8.065947.29719@sq.sq.com>, msb@sq.sq.com (Mark
Brader) writes:
|> > ... Again, the basic question is still unresolved here: can a conversion
|> > from one pointer type to another affect bytes other than those
|> > where the pointer variable is stored?
|> 
|> There is nothing in the standard to justify such an action, so it
|> would be permissible only under the "'as if' rule".  It could, for
|> example, modify bytes that the program mustn't read because the
|> behavior would be undefined, such as the bytes of an object of
|> indeterminate value.  It could modify the bytes of a volatile object.
|> But it could NOT modify some arbitrary object with a well-defined
|> value that the program correctly expects to persist!

Agreed, so far.

|> 
|> In particular, it could not modify padding at the end of a struct,
|> precisely *because* it would break the struct hack.

Ok. Finally we have the explanation: the struct hack is legal, because
otherwise it would be illegal. :)

Here is another explanation, why the compiler cannot add this kind of
type-check
information:  Malloc can (and often does) allocate a whole array of structures.
It cannot write the information to the end of *all* the structures (since it
does not know the number of elements).  The only solution would be to write
the information whenever a new pointer value to one of these structures
gets created (via casting, assignment AND POINTER ARITHMETIC).  But then there
is no point in keeping this information at all (because the whole idea was to
*probe* this information instead of freshly generating it).

(More objections, Dave?)

-Matthias
Newsgroups: comp.std.c