On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > is treated as if it points to a stream of bytes, where the first four are
????
I spy magic number.
> > > the length of the source to be read followed by the source. If set to
> >
> >Since you have a fourth argument couldn't that be used for the length
> >of the byte stream rather than embedding that length into the byte stream
> >itself? Makes more sense to me to separate the bytes from the length.
>
> I'd rather the stream be self-contained, rather than needing an extra
> argument for the length. Counted strings aren't uncommon outside of C, and
> there's no reason a Fortran or COBOL (or Java, or...) program can't embed perl.
Why four? Surely that's imposing an arbitrary binary structure. If it's a
parameter then it's (probably) a machine register and certainly a "natural"
quantity for whatever's running the code (and automatically the correct
endian-ness just in case perl is running in some (oddball partial)
binary emulation environment. Erm. Or something like that.
I forget the source of the quote, but it was to the effect of
C is the only language where not just the binaries but also the source is
not portably.
Say you'd said 2 not 4.
struct counted_file {
short count;
struct {
char bytes[1];
} file;
};
erm. can't have bytes[0]; because that's not portable.
Can't really be short because who said that that was 2 bytes?
For that matter I know of one compiler which doesn't have any type
sizeof(2), and sizeof (struct counted_file) is 8 here on this arm machine
:-) Wierdo but ANSI compliant alignment constraints.
[yes, I forced that one using the second struct inside the first]
Nicholas Clark
