All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] lm-sensors 3.0.0-rc1 has been released!
Date: Mon, 22 Oct 2007 13:55:08 +0000	[thread overview]
Message-ID: <20071022155508.57a0a283@hyperion.delvare> (raw)
In-Reply-To: <20070925233316.7afaa297@hyperion.delvare>

On Mon, 22 Oct 2007 15:15:51 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > On Mon, 22 Oct 2007 11:40:11 +0200, Hans de Goede wrote:
> >> I've also added a comment how to use it in future versions. The idea is to 
> >> increment the lower digit when for example new features are added to the 
> >> featuretype enum, so that applications can check the SENSORS_API_VERSION and 
> >> conditionally support new features for example (if they don't/can't check they 
> >> will no longer compile against an older libsensors).
> > 
> > I think I wouldn't have bothered. If applications no longer compile
> > with an older libsensors, then just upgrade libsensors.
> 
> That would mean much pain for distro developers which want to minimize churn, 
> but may still need to upgrade an application because of security reasons.

My experience is that distributions backport fixes for security bugs,
rather than upgrading to the next version of the application or the
library. But I don't actually think this is the right way to do it, so
I'll buy your argument :)

> > If someone is willing to maintain the API number, that's fine with me.
> > Me, I'll try to remember, but as I know myself, chances are good that
> > I'll forget sometimes if nobody is watching over me.
> 
> I'll try to keep an eye on it. I hope that if we forget users will complain.

The problem with this kind of thing is that, by the time users
complain, it's too late: you have a released version with a broken
define and you can't change that. So let's just hope it won't happen.

> > Just one thing I'm curious about: are you sure you want to set the API
> > to 400 _decimal_? Setting it to 0x400 instead seems to be more
> > flexible, as is allows for constructs like:
> > 
> > #if (SENSORS_API_VERSION >> 16) = 4
> > 
> > which is plain impossible to do with a decimal version number.
> 
> Well with mine one can do:
> #if (SENSORS_API_VERSION / 100) = 4
> 
> But I'm fine with either.

Ah right, I tend to forget that >> is nothing more than a division ;)
But... still, I think I'd feel more confident if we used hexadecimal.

> > Another thing: don't you want to define SENSORS_API_VERSION in trunk as
> > well? If not, you'll always have to test for SENSORS_API_VERSION's
> > existence before checking its value. I know that versions up to and
> > including 2.10.4 do not have the define and we can't change that, but
> > maybe applications will want to support all versions >= 2.10.5 so that
> > the #if magic can be limited to something sane.
> 
> Not necessary, if an identifier which is not a MACRO gets used in an #if 
> statement it is considered zero, so to take you example:
> #if (SENSORS_API_VERSION / 100) = 4
> 
> Would expand to:
> #if (0 / 100) = 4
> 
> And thus be false.

Unless the application is built with -Wundef (which is our case now),
in which case a warning is issued. That's what I would like to avoid.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2007-10-22 13:55 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25 21:33 [lm-sensors] lm-sensors 3.0.0-rc1 has been released! Jean Delvare
2007-09-25 21:45 ` Philip Edelbrock
2007-09-26 21:02 ` Hans de Goede
2007-09-27 14:35 ` Jean Delvare
2007-09-27 14:42 ` Jean Delvare
2007-09-27 17:53 ` Henrique de Moraes Holschuh
2007-09-28 17:07 ` Jean Delvare
2007-09-28 20:13 ` Henrique de Moraes Holschuh
2007-09-29 13:39 ` Jean Delvare
2007-09-30  0:56 ` Henrique de Moraes Holschuh
2007-09-30 11:54 ` Jean Delvare
2007-09-30 12:10 ` Jean Delvare
2007-09-30 14:54 ` Henrique de Moraes Holschuh
2007-10-03 10:36 ` Jean Delvare
2007-10-03 11:38 ` Henrique de Moraes Holschuh
2007-10-04  9:45 ` Jean Delvare
2007-10-04 12:49 ` Henrique de Moraes Holschuh
2007-10-04 13:42 ` Jean Delvare
2007-10-07 11:21 ` Axel Thimm
2007-10-17 21:44 ` Jean Delvare
2007-10-18  7:17 ` Hans de Goede
2007-10-18  8:18 ` Aurelien Jarno
2007-10-19 14:46 ` Jean Delvare
2007-10-19 20:18 ` Hans de Goede
2007-10-20 18:13 ` Jean Delvare
2007-10-20 22:41 ` Hans de Goede
2007-10-21 19:08 ` Jean Delvare
2007-10-21 19:13 ` Hans de Goede
2007-10-21 21:12 ` Jean Delvare
2007-10-22  7:06 ` Hans de Goede
2007-10-22  7:48 ` Jean Delvare
2007-10-22  8:13 ` Hans de Goede
2007-10-22  8:23 ` Jean Delvare
2007-10-22  9:40 ` Hans de Goede
2007-10-22 11:55 ` Jean Delvare
2007-10-22 13:15 ` Hans de Goede
2007-10-22 13:55 ` Jean Delvare [this message]
2007-10-22 19:27 ` Hans de Goede
2007-10-22 22:25 ` Aurelien Jarno
2007-10-24 15:30 ` Jean Delvare
2007-10-24 17:09 ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071022155508.57a0a283@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.