Re: Boost process and C

Flash Gordon wrote:
websnarf@xxxxxxxxx wrote:
Flash Gordon wrote:
websnarf@xxxxxxxxx wrote:
Ben C wrote:
On 2006-05-03, websnarf@xxxxxxxxx <websnarf@xxxxxxxxx> wrote:
CBFalconer wrote:
websnarf@xxxxxxxxx wrote:
CBFalconer wrote:
... snip ...
The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities
You perhaps would like to name one?
I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.
[snip]

[...] I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.
Your going to need to conceed on more grounds than that. There is a
reason many UNIX systems tried to add a ssize_t type, and why TR 24731
has added rsize_t to their extension. (As a side note, I strongly
suspect the Microsoft, in fact, added this whole rsize_t thing to TR
24731 when they realized that Bstrlib, or things like it, actually has
far better real world safety because its use of ints for string
lengths.) Using a long would be incorrect since there are some systems
where a long value can exceed a size_t value (and thus lead to falsely
sized mallocs.) There is also the matter of trying to codify
read-only and constant strings and detecting errors efficiently
(negative lengths fit the bill.) Using ints is the best choice
because at worst its giving up things (super-long strings) that nobody
cares about,
I think it's fair to expect the possibility of super-long strings in a
general-purpose string library.
Ok, so you can name a single application of such a thing right?
Handling an RTF document that you will be writing to a variable length
record in a database. Yes, I do have good reason for doing this. No, I
can't stream the document in to the database so I do have to have it all
in memory. Yes, RTF documents are encoded as text. Yes, they can be
extremely large, especially if they have graphics embedded in them
encoded as text.

So now name the platform where its *possible* to deal with this, but
where Bstrlib fails to be able to deal with them due to its design
choices.

If the DOS port hadn't been dropped then depending on the compiler we
might have hit this. A significant portion of the SW I'm thinking of
originated on DOS, so it could have hit it.

Oh ... I think of DOS as exactly the case where this *can't* happen.
Single objects in 16bit DOS have a size limit of 64K (size_t is just
unsigned which is 16 bits), so these huge RTF files you are talking
about *have* to be streamed, or split over multiple allocations
anyways.

it allows in an efficient way for all desirable encoding scenarios,
and it avoids any wrap around anomolies causing under-allocations.
What anomalies? Are these a consequence of using signed long, or
size_t?
I am describing what int does (*BOTH* the encoding scenarios and
avoiding anomolies), Using a long int would allow for arithmetic on
numbers that exceed the maximum value of size_t on some systems (that
actually *exist*), so when there was an attempt to malloc or realloc on
such sizes, there would be a wrap around to some value that would just
make it screw up. And if I used a size_t, then there would be no
simple space of encodings that can catch errors, constants and write
protected strings.
Is an extra byte (or word, or double word) for a flags field really that
big an overhead?

I need two *bits* for flags, and I want large ranges to catch errors in
the scalar fields (this is a *safe* library). An extra struct entry is
the wrong way to do this because it doesn't help my catch errors in the
scalar fields, and its space inefficient.

ssize_t would have been a reasonable *functional* choice, but its not
standard. size_t is no good because it can't go negative. long int is
no good because there are plenty of real platforms where long int is
larger than size_t. int solves all the main real problems, and as a
bonus the compiler is designed to make sure its the fastest scalar
primitive available.

Strangely enough, when a previous developer on the code I'm dealing with
thought he could limit size to a "valid" range an assert if it was out
of range we found that the asserts kept getting triggered. However, it
was always triggered incorrectly because the size was actually valid!

And how is this connected with Bstrlib? The library comes with a test
that, if you run in a 16 bit environment, will exercise length
overflowing. So you have some reasonable assurance that Bstrlib does
not make obvious mistakes with size computations.

[...] So I'll stick to not artificially limiting sizes.

And how do you deal with the fact that the language limits your sizes
anyways?

[...] If the administrator of a
server the SW is installed on wants then s/he can use system specific
means to limit the size of a process.

What? You think the adminstrator is in charge of how the compiler
works?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Boost process and C
    ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... If the DOS port hadn't been dropped then depending on the compiler we ... And how do you deal with the fact that the language limits your sizes ...
    (comp.lang.c)
  • Re: Boost process and C
    ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... I do have good reason for doing this. ... If the DOS port hadn't been dropped then depending on the compiler we ...
    (comp.lang.c)
  • Re: Boost process and C
    ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... Handling an RTF document that you will be writing to a variable length ... the scalar fields. ...
    (comp.lang.c)
  • Re: Comments concerning TR 24731
    ... It's not like we don't have any implementation experience with dynamic ... As far as I can tell, Bjorn Reese's dynamic strings and Paul ... This is how Bstrlib is different. ... are substantially recovered when using libraries like Bstrlib. ...
    (comp.std.c)
  • Re: DOS to WIN32 Redirector
    ... DOS PC gets a new drive which is a folder on a server2003 machine. ... List of supported functions in DR-DOS and CPhantom from "INT 2f ... FileMode fmode; ... FileAccess faccess; ...
    (comp.os.msdos.programmer)
Loading