xlsx2csv package may not be required.
There is a current pure python version of xlsx2csv which runs for many versions of Python 2 and Python 3. It may not be necessary to provide a package for it in cygwin. Instead, users may install the pure python package from PYPI https://pypi.org/ using pip or another python package manager. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Stepping down as Maintainer
Hi all, I (Doug Henderson) would like to resign from maintaining these four packages: expat mingw64-i686-expat mingw64-x86_64-expat xxhash I am no longer using cygwin, and have not done anything significant with it in close to five years. A linux laptop and msys64/mingw64 now meet all my requirements in my retirement. Cygwin was an enormously valuable feature when I was forced to work exclusively on windows systems during my professional career. Thanks to all the volunteers who made Cygwin so great. TTFN, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: github password policy
On Mon, 16 Aug 2021 at 07:45, ASSI wrote: > > Thomas Wolff writes: > > As I cannot update mintty anymore right now from the git command line, Yes, I use SSH for all repos now. > Do. Not. Use. GitHub. > > The raison raison d'être for GitHub is and always has been to subvert > the fully distributed workflow that Git was designed to provide and > replace it with their centralized lock-in "solution". As well as GidHub for several public repos, I have used BitBucket for several private repositories, as they allowed several, while GitHub only allowed one. They also have a large number of add on features around the Git repositories, aimed at lock-in. Does anyone have online Git servers they use and can recommend? BTW, I have done Google searches, etc. I'm looking for enthusiastic personal endorsements. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
[alternatives] building an app that uses gettext
HI, I have not previously built an app that uses gettext. The relevant parts of the makefile are: VERSION = 1.16 CFLAGS = -g -Wall -D_GNU_SOURCE LDFLAGS += -g alternatives: alternatives.o alternatives.o: alternatives.c $(CC) $(CFLAGS) -DVERSION=\"$(VERSION)\" -c alternatives.c I am getting many /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: /usr/src/alternatives-1.16-1.src/alternatives-1.16-1.x86_64/build/alternatives.c:1389: undefined reference to `libintl_gettext' messages while linking. I have installed the gettext-devel and libgettextpo-devel and libintl-devel packages, but I can't seem to properly rewrite the CFLAGS or LDFLAGS despite several attempts. Can someone recommend a simple cygwin package that uses gettext and the cygintl-8.dll TIA, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: attention alternatives maintainer
On Thu, 15 Jul 2021 at 19:56, Ken Brown via Cygwin-apps wrote: > > On 7/15/2021 7:07 PM, Doug Henderson via Cygwin-apps wrote: > > Please update alternatives to work properly for a first time install > > of an alternative when CYGWIN=winsymlinks:nativestrict. > > Cygwin doesn't have an alternatives maintainer. Would you like to volunteer? > If so, start at > >https://cygwin.com/packages.html > > and follow up on the cygwin-apps mailing list if you need help. I will volunteer to be the alternatives maintainer. I may need some help, though. The package has not been released for over 10 years, for cygwin 1.7, I think. The download location is worse than 404, it is "We can’t connect to the server at www.fastcoder". I found what appears to be a Fedora repository on GitHub that is in active development. https://github.com/fedora-sysv/chkconfig I'm getting ready to have a first look at the code. I think the packaging will be more of a problem than the code revisions. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
attention alternatives maintainer
Please update alternatives to work properly for a first time install of an alternative when CYGWIN=winsymlinks:nativestrict. See the recent thread on the cygwin mailing list with subject Setup shows errors from gnuplot-base.dash and python38-devel.sh In essence, when CYGWIN=winsymlinks:nativestrict., the first time it runs, a postinstall script for a package that uses alternatives will fail. Once it has succeeded once, it will subsequently run without error. In order to make it run I must set CYGWIN=winsymlinks:native, run the postinstall script in an elevated shell (or from setup). Then I can restore CYGWIN=winsymlinks:nativestrict. I think the link target must be created before the symlink is created. Without looking at the code, I suspect the order of two symlink needs to be reversed. The basis for the problem is the difference between POSIX and Windows symlinks.As I understand it, Windows symlinks need to :"know" if the target is a file or directory, while the POSIX symlink does not require the target to exist. Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: python update status
On Sun, 10 Jan 2021 at 21:13, Marco Atzeri via Cygwin-apps < cygwin-apps@cygwin.com> wrote: > Hi All, > > I am working on the next round of python pakages update. > > My highest priority update for Cygwin Python is for Python 3.9, followed by a test version of Python 3.10 when the RC release appears. I am writing all my code for Python 3.9 so without a Cygwin Python 3.9, I have lost the ability to test my apps with Cygwin. I write a lot of console apps, some Flask sites and a few Tkinter apps. I have the Python 3.10 alpha release installed on Win10 to check for breaking changes. I have PYTHINDEVMODE permanently set in my environment, as the overhead is not noticeable. I have absolutely no desire to run Python 2 code. I use "python -m pip ..." to install third party extensions, both pure Python and those requiring compilation. When this fails, I notify the maintainer or offer a fix to help improve the package's portability. I don't find the Cygwin packages built from pure Python packages to be of much value, unless they track the latest upstream updates very closely. As a result, I find that I end up with a lot of incomplete Cygwin Python packages where I have updated the package using pip. I'm retired now, but I always asked for local admin or sudo for the 20 odd years when I was a contractor. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: [ITP] xxhash 0.7.4-1
On Sun, 2 Aug 2020 at 04:41, Ben RUBSON <> wrote: > > On 14 Jul 2020, at 21:51, Doug Henderson via Cygwin-apps <> wrote: > > > > I have patched the Makefile as suggested. The newest version of the > > dist files as located at > > > > https://github.com/djhenderson/Temp/raw/master/xxhash.zip > > Any way, I would like some critical feedback on the dist packaging. > > Hi, > > Not sure about the whole integration process, but any news perhaps regarding > this package release ? > > Thank you very much, > > Kind regards, > > Ben I have not received any feedback on the current packaging, nor an enthusiastic buy in for the package. Apparently a version of the code is already packaged in the zstd package because that package uses xxhash. Please see if that will work for your use case and report back here. Thanks. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: [ITP] xxhash 0.7.4-1
On Tue, 14 Jul 2020 at 10:29, ASSI <> wrote: > > ASSI writes: > > By patching the Makefile, just like you need to do for all the other > > stuff from the same author. You can have a look at the zstd packages. > > Come to think of it, xxhash is already part of zstd. Can't you just > link to that? > > > Regards, > Achim. I have patched the Makefile as suggested. The newest version of the dist files as located at https://github.com/djhenderson/Temp/raw/master/xxhash.zip I compared the xxhash sources between the xxhash repo and the zstd repo. There are major differences in the code. This is obvious from wc $ wc -l /usr/src/xxhash.src/xxhash-0.7.4-1.x86_64/origsrc/xxHash-0.7.4/xxhash.c /usr/src/zstd-1.4.5-1.src/zstd-1.4.5-1.x86_64/origsrc/zstd-1.4.5/lib/common/xxhash.c 43 /usr/src/xxhash.src/xxhash-0.7.4-1.x86_64/origsrc/xxHash-0.7.4/xxhash.c 864 /usr/src/zstd-1.4.5-1.src/zstd-1.4.5-1.x86_64/origsrc/zstd-1.4.5/lib/common/xxhash.c 907 total $ wc -l /usr/src/xxhash.src/xxhash-0.7.4-1.x86_64/origsrc/xxHash-0.7.4/xxhash.h /usr/src/zstd-1.4.5-1.src/zstd-1.4.5-1.x86_64/origsrc/zstd-1.4.5/lib/common/xxhash.h 2076 /usr/src/xxhash.src/xxhash-0.7.4-1.x86_64/origsrc/xxHash-0.7.4/xxhash.h 285 /usr/src/zstd-1.4.5-1.src/zstd-1.4.5-1.x86_64/origsrc/zstd-1.4.5/lib/common/xxhash.h 2361 total I had a brief look at the code, but did not attempt to judge the merits of either code base. The zstd repo does not include the xxhsum command which has a similar CLI to cksum, md5sum, sha256sum, etc. Apparently xxhash will use the SSE2 instructions for some operations. Someone with an older CPU without those instructions should test to make sure the xxhsum programs works for them. (I'm just saying that, I don't really know what that means.) Any way, I would like some critical feedback on the dist packaging. Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
[ITP] xxhash 0.7.4-1
Hi, I am volunteering to be the maintainer for xxhash. This is my first ITP, so I'm sure that I don't have everything right. The package is currently distributed on, at least, Ubuntu and Archlinux. The library files xxhash.c and xxhash.h are BSD licensed. The utility xxhsum is GPL licensed. The package compiles cleanly and all tests run successfully, without any cygwin specific patches. You may download the current version of the dist files from https://github.com/djhenderson/Temp/raw/master/xxhash.zip I have some issues to resolve. The install places files into the /usr/local tree instead of the /usr tree. Usually I would just do "PREFIX=/ make", but that does not work, so I'm not sure how to do this from the cygport file. How do I change the name of the shared library to something like cygxxhash.0.dll? Do I need the libxxhash.a file? I think I should split the package into devel and non-dev packages..Again, I'm not sure how to do that. Or if that is necessary. I am currently the maintainer for expat, mingw64-i686-expat, mingw64-x86_64-expat packages. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Attention ninja maintainer
Hi, ninja installs its bash completion script in /etc/bash-completion.d Other bash completions are installed to /etc/bash_completion.d Please look into this. Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: [PATCH] cygport install infinite loop when symlink in path
On Mon, 13 Jul 2020 at 07:13, Brian Inglis <> wrote: > src_postinstall(_prep_libtool_modules): infinite loop when symlink in path > added readlink to also resolve symlinks in path to DEST host prefix > --- > lib/src_postinst.cygpart | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Brian, Please check that this patch works properly when CYGWIN=winsymlinks:nativestrict I have encountered problems when running cygport with this setting due to the different behavior of unix symlinks and windows symlinks vis-a-vis attempting to create a symlink that points to a non-existent location. [ https://cygwin.com/cygwin-ug-net/using-cygwinenv.html] My simplistic solution was to force CYGWIN=winsymlinks.native in the .cygport file. Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: Cygport user guide
On Tue, 9 Jun 2020 at 09:56, marco atzeri via Cygwin-apps wrote: > > On Tue, Jun 9, 2020 at 3:23 PM Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> > > I suspect the user base is too small to justify the effort and I am afraid > every > major package needs a different approach. I find that I need an overview document to get me back up to speed when I haven't used cygport for a while. The existing document, which describes a very simple cygport file is a start, but stops way too soon. I'd like to see a high level description of how cygport works. If reading about some other packaging system would be helpful, I would like to see a link to such documentation. Recently, I used cygport to automate the building of an app that I will probably never ITA (it compiles cleanly, runs fine, but does not actually work on Windows). I knew it used cmake, but I had to grep through setup.ini to find the packages that had a development dependency on cmake, and get the source packages to figure out how their cygport files worked. (It's just a one line change, but it needs to be the right line!). There is generated documentation, but it needs to be fleshed out to be useful. Doing that, in an incremental fashion, might be a route to make more helpful documentation. Uncharitably, that sounds like asking one person to take on the bulk of the work. Perhaps those of us that occasionally have to dig into the cygport code could git clone cygport and make a personal branch to add some few words to any functions we happen to study. Hopefully pull requests for comment only changes should be easy to approve and merge. Thoughts? Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: Putting packages up for adoption
On Thu, 19 Mar 2020 at 22:03, Yaakov Selkowitz <> wrote: > Hello Cygwin package maintainers, > > > > To that end, in the best interest of the community, please consider my > packages up for adoption. I don't expect that any one person will take > all of them; some are obsolete and due for removal anyway, some should > be picked up as soon as possible, and others might just end up > bitrotting if nobody is interested in them. However, in whatever there > is interest (or need), hopefully what is there now will serve as a > strong foundation to on which to continue to build. > > > I will pickup the mingw64-i686-expat and mingw64-x86_64-expat packages, as I currently maintain the expat package Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: cygport development
On Mon., Oct. 14, 2019, 02:55 Federico Kircheis, <> wrote: > On 13/10/2019 18.41, Achim Gratz wrote: > > Federico Kircheis writes: > >> I've sent the patches the 14.07.19, unfortunately I still got no answer. > > > > The cygport maintainer is rather busy with non-Cygwin related work these > > days, I suppose. Anyway, one of the questions I have is why you need > > these changes. Most build systems do not actually work when they > > encounter a path with spaces if they use make under the hood, so fixing > > cygport to grok such path locations isn't getting you much further I'd > > think. Can you explain? > > Yep. > > I've built some software in my windows home directory. > It contains a space. > I expected it to work. > > Instead of failing with a clear error message, the build process deleted > some unrelated files as it cd failed (or cd in the wrong directory, cant > remember right now). > > I believe it is unacceptable to delete unrelated data. > > Even if it stated that there is no intention to support path with > spaces, those scripts should fail fast and ideally with a clear error > message. > > I found it easier to quote the offending variables, as not only spaces > might cause issues. > When I encountered a similar problem, I added code to quote env variables that had spaces until cygport worked correctly. Then I submitted patches to this list and the maintainer so the current code works for my problem case OOB. This is the best and fastest way to get your problem fixed, and, as a bonus, get credit as a contributor to open source software. Doug >
Re: rebuilding python pip from source
On Mon, 4 Mar 2019 at 09:39, Yaakov Selkowitz <> wrote: > > On Mon, 2019-03-04 at 04:57 -0700, Doug Henderson wrote: > > I am trying to rebuild the python37-pip package from source. > > Checking source in setup gives me /usr/src/python-pip-19.0.2-1.src/ > > When I try to build the package I get an error: > > > > $ cygport python-pip.cygport all > > *** ERROR: python27-pip is required to build this package > > > > Initially I got errors saying python36-pip, etc. were required, so I > > installed the binary and source packages for them, but there is no > > python27-pip or python2-pip package available to install. > > There is: https://cygwin.com/packages/x86_64/python27-pip/ I have that package installed. I want to be able to compile it from source, as a small step towards my ultimate goal. > > Ultimately I intend to completely rebuild from source both Python 2.7 and > > 3.7 > > and all the other packages named "^python.*". > > To what end? Because that is a right granted to me by the open source license under which some source code is released. Perhaps not explicitly by the Python and cygwin licences, but as an implied ability. What is the point of having a source package but to be able to rebuild the binary package. For me, it is more a learning process than anything else. I understand that you are the maintainer of the main Python packages, as well as many other related packages. Thank you for your contributions. I must keep you very busy, so automating the process using cygport makes a lot of sense. There are other python related packages maintained by others, or orphaned. Starting with pip seemed a good idea. Previously, before python3 was available on cygwin, I rebuilt python2 from source, and also attempted to port python3. I don't think I used cygport back then. Back in the early 80's I received gcc, emacs, X11, sun-rpc, etc. on 9 track tape, and built them on the wide variety of Unix workstations and servers in our office. And over the years I built Python every where I had a C compiler but no Python. Building software from a source distribution is not a problem for me. Currently I maintain the cygwin expat package. I suspect that the Python build process requires some manual steps in addition to perhaps running cygport in small step, or even editing the.cygport file between those steps, that are not obvious from examining the source package. I suspect there is a recipe that you use every time you build a new Python release. I hope you can share that with me. I am thinking about porting some other packages to cygwin, and Python represents a complex system of packages that appears to make good use of cygport. Along the way, I need a better understanding of cygport, and how to wrap a provided build system within it. Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
rebuilding python pip from source
I am trying to rebuild the python37-pip package from source. Checking source in setup gives me /usr/src/python-pip-19.0.2-1.src/ When I try to build the package I get an error: $ cygport python-pip.cygport all *** ERROR: python27-pip is required to build this package Initially I got errors saying python36-pip, etc. were required, so I installed the binary and source packages for them, but there is no python27-pip or python2-pip package available to install. Ultimately I intend to completely rebuild from source both Python 2.7 and 3.7 and all the other packages named "^python.*". Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Proposed patch for cygport to fix homepage command
Hi,
The "cygport homepage" command fails in two situations.
1. The default install location for Firefox 64 in WIn7 64 is
"C:\Program Files\Mozilla Firefox\firefox.exe"
To use this from cygwin, it must be convert with "cygpath -u" and
results in a path name which includes spaces, and thus require
quoting. Cygport will use the BROWSER environment variable, when set,
but it does not quote the value everywhere it is used.
2. If the package does not include a HOMEPAGE variable, cygport
defaults to searching google for the program name, e.g.:
"http://www.google.com/search?q=${ORIG_PN:-${PN}};
however it does not quote the value everywhere it is used.
The attached patch quotes the path to the browser executable, and the
homepage URL at all locations where they are used.
HTH,
Doug
--
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
cygport-0.24.1-2.src.patch
Description: Binary data
Re: ITA nasm
On 29 June 2017 at 09:38, Marco Atzeri wrote:
> On 29/06/2017 17:22, Doug Henderson wrote:
>>
>> I am willing to take over maintenance of the nasm package.
>>
>> Info for current release:
>>
>> # package name
>> NAME="nasm"
>> VERSION=2.10.07
>> RELEASE=2
>
>
> are you planning to just align the x86 and x86_64 version ?
> It is worth ?
>
>>
>> # .hint generation
>> CATEGORY="Devel"
>> SUMMARY="The Netwide Assembler"
>> DESCRIPTION="NASM is a widespread, portable, very flexible and mature
>> assembler tool with support for many output formats licensed under the
>> 2-clause BSD licence."
>
>
> it misses the info about where to download the source
>
>> I plan to package 2.13.01-0 based on the latest upstream release.
>
>
> better 2.13.01-1 as we are using "-0.x" for test pre-release when needed
>
Source and download:
# source and patch files
HOMEPAGE="http://www.nasm.us/;
SRC_URI="http://www.nasm.us/pub/nasm/releasebuilds/${PV}/${P}.tar.xz;
I have changed initial release number to 1
I will keep both 32 bit and 64 bit versions at the same version to the
extent possible. I'm not sure why the current versions are at
different numbers, unless an upgrade was requested for 64 bit only.
Doug
--
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
ITA nasm
I am willing to take over maintenance of the nasm package. Info for current release: # package name NAME="nasm" VERSION=2.10.07 RELEASE=2 # .hint generation CATEGORY="Devel" SUMMARY="The Netwide Assembler" DESCRIPTION="NASM is a widespread, portable, very flexible and mature assembler tool with support for many output formats licensed under the 2-clause BSD licence." I plan to package 2.13.01-0 based on the latest upstream release. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: units issues
, On 24 May 2017 at 18:16, Brian Inglis wrote:
> I would appreciate it if anyone has any experience with, or can point me
> to, any python3 code in any Cygwin package which works Windows proxy
> authentication?
I had a glance at the source. I recall adapting it to load SQL tables
with units data. I recall writing code very similar to that in the
units_cur{2|3} python sources to keep the table current.
units_cur2 is the python2 version, units_cur3 is the python3 version
of the updater.
It is using the urllib and ElementTree packages which are parts of the
standard python release.
A possibly more featureful replacement for urllib is the requests
package, available in the cygwin packages python2-requests and
python3-requests. See http://docs.python-requests.org/en/master/ for
the documentation. It claims "HTTP(S) Proxy Support" however I have
not used that feature.
There are two similar lines that use urllib:
... urllib.request.urlopen('URL1>') ...
... urllib.request.urlopen('?f=xml') ...
Using requests, they become:
... requests.get('').text ...
... requests.get('', params={'f':'xml'}).text ...
Some additional code is required to support proxies, but I can't help
much there.
See http://docs.python-requests.org/en/master/user/advanced/#proxies for info.
HTH
Doug
--
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: units issues
On 23 May 2017 at 15:49, Brian Inglis wrote: > Updating the currencies only when setup is run seems to me to be > insufficient if users want to use current currency conversions. Currencies needs to be split to a different package from non-currency units. Non-currency units is very static, whereas most currencies changes daily. In the absence of updates, non-currency units are still useful; but currencies are incorrect in most cases, and increasingly so as time pass. It is difficult to predict user requirements based on current package dependencies as non-currency units and currencies are likely used by almost disjoint sets of packages. Users of non-currency units should not be burdened by the complexities of currencies. But if they do need currencies, they should be up to date. A possible solution is to check the currency of the currency data on library initialization or each use by comparing the current date with the data's date of update. When the data is stale, automatically update it if possible, or notify the user of the problem. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
SSH key for upload access
Name: Doug Henderson Package: expat BEGIN SSH2 PUBLIC KEY Comment: "2048-bit RSA, converted by Doug@Rover from OpenSSH" B3NzaC1yc2EDAQABAAABAQDPTrLvKclWJegvNRqP49FMcwUFdfPvbX6Z8qfBRG jo6wf+mRTXIn/zWHQyeg30bz9x64b6beXM1qiDmcRrkGpKo7ejuP6XC5clI2v5dZubFTRK cvQ/lIWxZiIaYVuILInMFDBOnqZOj7TYxlK/GTwLXP/bc6/J9EuhC7UOm7xEwsXREqgxmY mhQXsjOb5OU76Hn15Wz9fWGU3tOCHuwW5/aexVj53SG/s5/SNpGNus9kxFmOfywe960W/c 5n3xhJSMhWOwQx4Uxh57HjVPIyDif8YlEMSH5dalk61pePuMkyCvllYMsG4aZl+jhgmO03 itqDBFhWdX3PE8fUXWJboL END SSH2 PUBLIC KEY
Re: Up for adoption: ctags and expat
On 12 August 2016 at 11:57, Warren Young wrote: > On Aug 12, 2016, at 7:57 AM, Corinna Vinschen wrote: >> >> >> Cool! If you want to take over ctags and test universal ctags for >> Cygwin, feel free if Warren agrees. I'll change over maintainership >> then. >> >> Warren, does that sound good to you? >> >> Doug, I hope you don't feel overlooked. Expat is still yours if >> Warren has no problems with that. > > Sounds like a plan. Sound good to me. Right now I am between contracts/jobs, so I have a little more free time than usual. What should a new maintainer do now, pending upstream announcement of new releases or security patches? Doug -- Doug Henderson, Calgary, Alberta, Canada
Re: Up for adoption: ctags and expat
On 11 August 2016 at 17:49, Warren Young <w...@etr-usa.com> wrote: > I’m the current maintainer of these two packages. As it happens, > The time has come for someone else to maintain these packages. I am willing to take over as maintainer of the ctags and expat packages. Doug -- Doug Henderson, Calgary, Alberta, Canada
Re: Dodgy functions (finitel, strold)
On 25 March 2016 at 02:59, Achim Gratz <strom...@nexgo.de> wrote: > > Achim Gratz writes: > > Achim Gratz writes: > >> Long story short, they seem to report a finite value on at least some > >> NaN constructs and then the %a format for the Perl sprintf outputs those > >> bits as a hex FP number rather than just printing "NaN". On 64bit the > >> culprit is actually finitel, of course, since Perl gets compiled with > >> long doubles. > > > > And looking into newlib this seems to be a compile bug, because the > > function just uses an intrinsic. > > But the compiler is innocent, because newlib uses the wrong intrinsic or > an incomplete implementation. If it must be using that intrinsic for > compatibility reasons, it would need to implement > > > > Regards, > Achim. > I modified your program to display the actual hex value of the a, b, and c variables. The b and c variables have different bit patterns. It appears that the %a format conversion is (correctly) detecting ±inf and NaN according to IEEE 754, and ignoring the value of all other bits in the variables. It appears that strtold and the implicit conversion from double to long double are setting some of the bits which are not used to represent NaN or ±Inf to different values. It appears that some of the different functions that get used to detect finiteness and validity are sensitive to the setting of other bits in the values, or are expecting particular values for these bits. The standard supports two representations of NaN: a signalling NaN and a non-signalling NaN. From what I could see, the C language does not distinguish between the two NaN representations, but I did not look at the standards docs. HTH, Doug -- Doug Henderson, Calgary, Alberta, Canada
