Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. IMHO, this is a peculiar statement. The type 'char' is best suited to things that are characters or bytes. For array indices, int tends to be a better choice: most CPUs cannot read single bytes any faster than machine words; compilers allocate registers at their full width; some architectures (68K for proper sign extension) sometimes require extra instructions in order to perform sub-word width math; careless alignment can be a problem with sub-word values packed into structures. Obviously, a compelling reason for 'char' as an index is when storing many of them, but in such a care must be taken to write what you mean and declare unsigned-ed-ness when that is what you want. Cheers.
NFS Servers, deadlocks and symlinks
I'll start with the question(s) for the impatient. Is anyone experiencing deadlocks between nfs-kernel-server and ext3? How about symlink errors using nfs-user-server? There is nothing in the debian bugs database about either of these problems. Nor is there anything about the ext3 deadlock in google. Background. I've been using the kernel server for nearly a year to provice NFS to an NCD xterm. It worked fine. This afternoon, while experimenting with Etherboot and it's need for an NFS server, a reiserfs partition I was using refused to mv bin .. where bin was a directory. The machine deadlocked, forcing me to reboot and wait 45 minutes while the raid fsck'd. After the second go at this, I decided it was time to enable journaling on the ext2 partitions. The discovery was that when I enabled ext3 on the partition that the NCD was NFS mounting to, the NFS mount would deadlock the machine. Switching to the nfs-user-server eliminated the deadlock. (A toast to apt-get.) Starting back on the original project, the Etherboot finally succeeded The next discovery was that the newly network-booted machine was experiencing NFS errors complaining about too many symlinks. It's root filesystem is mounted from server:/tftpboot/seashore which is a symlink to /a/dev/sde1/seashore. I wouldn't expect this to be a problem. Should I?
Appropriate? mutt/mailx requires mail-transport-agent
I'm working on a diskless workstation configuration where I don't want mailers running on each machine, though users may have access to the mail spool through nfs. Is it appropriate for apt-get to coerce exim to be installed when I only need a reader? Is this a problem about finding the smtp agent?
Re: Appropriate? mutt/mailx requires mail-transport-agent
On Mon, Jan 07, 2002 at 10:22:44PM +, Phil Blundell wrote: > >I'm working on a diskless workstation configuration where I don't want > >mailers running on each machine, though users may have access to the > >mail spool through nfs. Is it appropriate for apt-get to coerce exim > >to be installed when I only need a reader? Is this a problem about > >finding the smtp agent? > > What do mailx and mutt do if you try to send mail and no MTA is installed? > Unless they handle this situation gracefully, which doesn't seem all that > likely, this dependency is correct. My objection is simply that while there is a need for an available SMTP server, there is no need for it to be local. I'm going to look into some alternatives and post a recommendation.
Re: Appropriate? mutt/mailx requires mail-transport-agent
On Mon, Jan 07, 2002 at 02:13:02PM -0800, [EMAIL PROTECTED] wrote: > I'm working on a diskless workstation configuration where I don't want > mailers running on each machine, though users may have access to the > mail spool through nfs. Is it appropriate for apt-get to coerce exim > to be installed when I only need a reader? Is this a problem about > finding the smtp agent? Thanks for the replies. I believe that my confusion was founded in the idea that an MTA both sends and receives mail. The ssmtp package is an appropriate provider for the sendmail portion of the mail-transport-agent without the corresponding burden of a local mail receiver. Cheers.
Please don't do this (code fragment)
int i;
for (i = 0; i > -1; i += 1) {
// ...
if (terminal_condition)
break;
// ...
}
Let me be more explicit. I'm reading the slocate code to figure out
why it isn't producing a database on my machine. There is a loop that
reads
int i;
// ...
for (i = 0; i > -1; i+=1) {
file = fts_read(dir);
if (!file)
break;
// ...
}
The code example from the source is even more inappropriate than my
first example since there is no reason to avoid testing the terminal
condition in the loop construct. While there will be times when it is
difficult to compose a succinct for declaration, this is not one of
those cases.
int i;
for (i = 0; (file = ftp_read (dir)) != NULL; ++i) {
// ...
}
Moreover, i is never used. The loop could be reduced to
while ((file = fts_read (dir)) != NULL) {
// ...
}
Re: Please don't do this (code fragment)
On Mon, Jan 14, 2002 at 07:01:17AM +0100, Samuel Tardieu wrote:
> On 13/01, [EMAIL PROTECTED] wrote:
>
> | int i;
> | for (i = 0; i > -1; i += 1) {
> | // ...
> | if (terminal_condition)
> | break;
> | // ...
> | }
> [...]
> | Moreover, i is never used. The loop could be reduced to
> |
> | while ((file = fts_read (dir)) != NULL) {
> | // ...
> | }
>
> Those are not equivalent: the first loop, while ugly, has a guard against
> endless looping if fts_read always returns non-NULL for any reason (not
> knowing what fts_read contains, it is hard to tell whether there is a
> reason for this or not).
A poor reason to write that code for several reasons.
1) It bounds the loop to the size of the integer /2 without
explicitly indicating so.
2) If there is a problem, it silently hide the fact.
3) It is non-deterministic. Should the loop fail to terminate
properly, the program will run for a relatively long time. 15
seconds on the PIII 700MHz I'm using.
While I don't agree that this is an appropriate method for
guaranteeing termination, the same result with clearer expression
would be
int loop_max = MAX_INT;
while ((file = fts_read (dir)) != NULL && --loop_max) {
}
I'd rather see the program fail to terminate so that I knew something
was awry instead of imposing an unforseen limitation on the program.
Moreover, the original depends on the fact that (MAX_INT + 1) < 0
which, though true, is a guaranteed result. Were I to be running a 64
bit CPU, the time to terminate either of these loops would approach
infinity (2^32*15s)->~2042 years. I don't see the point of using such
a weak attempt to guarantee termination.
Cheers.
Re: Please don't do this (code fragment)
Reply-To:
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, Jan 13, 2002 at 10:49:09PM -0800, Craig Dickson wrote:
> [EMAIL PROTECTED] wrote:
>
> > On Mon, Jan 14, 2002 at 07:01:17AM +0100, Samuel Tardieu wrote:
> > > On 13/01, [EMAIL PROTECTED] wrote:
> > >
> > > | int i;
> > > | for (i = 0; i > -1; i += 1) {
> > > | // ...
> > > | if (terminal_condition)
> > > | break;
> > > | // ...
> > > | }
> > > [...]
> > > | Moreover, i is never used. The loop could be reduced to
> > > |
> > > | while ((file = fts_read (dir)) != NULL) {
> > > | // ...
> > > | }
> > >
> > > Those are not equivalent: the first loop, while ugly, has a guard against
> > > endless looping if fts_read always returns non-NULL for any reason (not
> > > knowing what fts_read contains, it is hard to tell whether there is a
> > > reason for this or not).
> >
> > A poor reason to write that code for several reasons.
>
> Samuel wasn't defending the original code; he was just observing that
> your suggested replacement was not functionally equivalent. Which it
> wasn't.
That is the crux of my argument. In a 64 bit environment, this code
as written *is* equivalent to my rewrite.
> > 1) It bounds the loop to the size of the integer /2 without
> > explicitly indicating so.
>
> It's pretty clear if you understand how twos-complement arithmetic
> works. Which is not to say it's the right thing to do,
Of course that is true. Yet, such practices define poor style. The
original author isn't writing what he means. The fact that 2's
complement arithmetic wraps is a side-effect. At least the use of
MAX_INT is an honest expression of the loop intent.
> but I've seen code that is much harder than this to understand.
And your point is what? I'm saying nothing about the difficulty of
reading the code. There is little point in having that discussion.
> > 3) It is non-deterministic. Should the loop fail to terminate
> > properly, the program will run for a relatively long time. 15
> > seconds on the PIII 700MHz I'm using.
>
> The original code is deterministic (the loop will definitely exit sooner
> or later); your suggested replacement is not, unless it is guaranteed
> that fts_read will eventually return NULL.
This is the kind of code that tends to break as systems evolve. When
we moved from 16 bit to 32 bit, dependencies on machine organization
broke many programs that depended on them. As I wrote in my reply, a
64 bit machine would have the same observable behavior as one without
the weak loop-termination guarantee. Anything that requires more than
a month to terminate when one expects it to terminate in a few of
minutes has effectively hung.
> > While I don't agree that this is an appropriate method for
> > guaranteeing termination, the same result with clearer expression
> > would be
> >
> > int loop_max = MAX_INT;
> > while ((file = fts_read (dir)) != NULL && --loop_max) {
> > }
>
> That's clearer, yes. It still sucks, unless there's a really good reason
> to use MAX_INT as the limit. It's hard to say without knowing more about
> the context of this tiny fragment of code, but I would guess that since
> the loop condition is only used to guarantee eventual termination, the
> limit could reasonably be set to a constant that is consistent across
> platforms (whatever that constant might be -- 10^3, 10^6, 10^9,
> whatever), rather than one that will vary by multiple orders of
> magnitude depending on whether the target system uses 16-, 32-, or
> 64-bit ints.
Still a poor choice. You are hiding a limitation in the code that is
neither appropriate nor desirable. Limiting the number of files, no
matter how you do it, will always change the semantics of the program.
Can you imaging people's suprise when the generate a search database
that appears to be missing a file that they know exists? Setting a
time limit on the program run may be a more reliable standard; but
this, too, will be difficult to bound. A process that runs without
bound will, at least, make itself known by loading the system.
>
> > I'd rather see the program fail to terminate so that I knew something
> > was awry instead of imposing an unforseen limitation on the program.
>
> I'd rather see the program send a useful diagnostic message to stderr or
> a log file, and either exit or properly recover from the error.
Of couse. I agree that the code would be better if there was a
reasonable bound on the extent of the loop *AND* it reports that
something went awry. But what should be the criteria?
The point is that the original code fragment fails to perform the
desired task deterministicly. Within a few years, there will be a
significant number of machines running 64 bit CPUs. Programs that use
this poor expression will be no better than those that don't. I
believe this is the sort of failure-protection that Linus Torvalds
complains about. Silently tolerating an error is worse than
discovering it when
Re: Please don't do this (code fragment)
On Mon, Jan 14, 2002 at 03:36:48PM +0100, Guus Sliepen wrote: > On Mon, Jan 14, 2002 at 12:04:44AM -0800, [EMAIL PROTECTED] wrote: > > [How to write bad code] > > Why don't you "man fts_read" and implement the correct way of checking > for errors? I believe the author wrote the original loop because the fts_ functions could fail to operate as expected. > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <[EMAIL PROTECTED]>
Re: Please don't do this (code fragment)
On Mon, Jan 14, 2002 at 06:01:37PM +0100, Guus Sliepen wrote: > On Mon, Jan 14, 2002 at 08:58:57AM -0800, [EMAIL PROTECTED] wrote: > > > > Why don't you "man fts_read" and implement the correct way of checking > > > for errors? > > > > I believe the author wrote the original loop because the fts_ > > functions could fail to operate as expected. > > Well please check if the author's assumptions are valid, and if so, > direct your attention to fixing fts_read(), everyone would benefit. The > discussion of how to make that ugly loop look "nicer" is useless. I think you are missing the point. As far as the program is concerned, there is no valid reason to use the protecting loop to guarantee termination. I, too, agree that there is no reason to make the loop nicer since there is no reason to write it in the first place. > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <[EMAIL PROTECTED]>
Re: Please don't do this (code fragment)
I don't find any such mention in K&R [1978]. There is nothing I can see to guarantees that MAX_INT + 1 < 0. On Tue, Jan 15, 2002 at 12:56:19AM +0100, Torsten Landschoff wrote: > On Mon, Jan 14, 2002 at 10:03:59AM -0800, Thomas Bushnell, BSG wrote: > > > I yet have to see a machine that does not use two's complement > > > for integer arithmetic. > > > > Actually, the C standard does essentially guarantee two's complement > > arithmetic. It specifies integer overflow behavior and > > signed/unsigned conversion behavior exactly. > > For real? Is that new with ISO C or was that in the original ANSI C > standard as well? Sorry, I gave away my ANSI C book a while before > and did not yet get it back :(( > > cu > Torsten
Re: Please don't do this (code fragment)
Good grief. Can you be more constructive? Do you have a reference that supports the claim? On Tue, Jan 15, 2002 at 12:11:35AM -0800, Thomas Bushnell, BSG wrote: > [EMAIL PROTECTED] writes: > > > I don't find any such mention in K&R [1978]. There is nothing I can > > see to guarantees that MAX_INT + 1 < 0. > > K&R [1978] is not the C standard.
Re: Vancouver keysigning request
I'm in Seattle, Washington. I'll keep your addresses on file for when I make my next visit to BC. On Sat, Apr 13, 2002 at 05:10:46PM -0700, Norman Jordan wrote: > I am a developer in Victoria. I don't go to Vancouver very often but I > can sign keys for people in Victoria. > > On Sat, Apr 13, 2002 at 04:52:05PM -0700, Carl B. Constantine wrote: > > Well, I'm in the process myself, and I'm in Victoria. If I make it in, > > I'll try to remember to contact you. > > * Shaun Jackman ([EMAIL PROTECTED]) wrote: > > > I'm looking for a Debian developer in Vancouver, Canada to sign my key. > > > If > > > you fit the bill, please reply! > > > > > > Thanks, > > > Shaun Jackman > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
