alexo <alelvb@inwind.it>: Feb 27 01:38PM +0100
> Where does it fail?
> How does it fail?
> What's it doing at the time?
The debugger doesn' stops on error. There is not a segfault or similar.
My program simply continues to send data and "hangs".
If I close it with xkill transmission doesn't end. It continues to keep
data transfer to I don't know who.
|
alexo <alelvb@inwind.it>: Feb 27 01:42PM +0100
> Where does it fail?
> How does it fail?
> What's it doing at the time?
The debugger doesn't stops on error. There is not a segfault or similar.
My program simply continues to send data and "hangs".
If I close it with xkill data transmission doesn't end.
|
"Öö Tiib" <ootiib@hot.ee>: Feb 27 05:15AM -0800
On Saturday, 27 February 2016 14:39:24 UTC+2, alexo wrote:
Restoring attributions, do not erase those. :(
> My program simply continues to send data and "hangs".
> If I close it with xkill transmission doesn't end. It continues to keep
> data transfer to I don't know who.
You apparently did not understand what Christopher asked. Possibly you
don't know what debugger is. Debugger is a tool. It does not "debug" on
its own. It helps you to find bugs.
Now can you please break the program with debugger and look:
Where does it "hang"?
How does it "hang"?
Why does it "hang"?
What's it doing at the time of "hanging"?
|
alexo <alelvb@inwind.it>: Feb 27 06:44PM +0100
>> As JiiPee suggested, I've found a very powerful library named curl.
>> The one he suggested, mimetic, has a bug.
> Namely?
after ./configure
make fails due to errors in the source files
|
alexo <alelvb@inwind.it>: Feb 27 06:59PM +0100
> How does it "hang"?
> Why does it "hang"?
> What's it doing at the time of "hanging"?
This is the source code of the toy program. It is executed correctly
but for the login you obviously have to type in your username password
and smtp server address.
when I insert this code in my program,
This code being called by pressing a button on the GUI transmission goes
forever.
the line that fails is this:
res = curl_easy_perform(curl);
It starts the transmission of the data and should return.
This is not what happens. The funclion locks the wireless transmission
and after closing the software with xkill, data transmission still
continues, but no mail starts.
/***************************************************************************
* _ _ ____ _
* Project ___| | | | _ \| |
* / __| | | | |_) | |
* | (__| |_| | _ <| |___
* \___|\___/|_| \_\_____|
*
* Copyright (C) 1998 - 2016, Daniel Stenberg, <daniel@haxx.se>, et al.
*
* This software is licensed as described in the file COPYING, which
* you should have received as part of this distribution. The terms
* are also available at https://curl.haxx.se/docs/copyright.html.
*
* You may opt to use, copy, modify, merge, publish, distribute and/or sell
* copies of the Software, and permit persons to whom the Software is
* furnished to do so, under the terms of the COPYING file.
*
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY
OF ANY
* KIND, either express or implied.
*
***************************************************************************/
/* <DESC>
* SMTP example showing how to send e-mails
* </DESC>
*/
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <cstdlib>
#include <curl/curl.h>
/* This is a simple example showing how to send mail using libcurl's SMTP
* capabilities. For an example of using the multi interface please see
* smtp-multi.c.
*
* Note that this example requires libcurl 7.20.0 or above.
*/
#define FROM "<alelvb@inwind.it>"
#define TO "<alessandro.volturno@libero.it>"
//#define CC "<alelvb@inwind.it>"
char *current_date();
char *date = current_date();
static const char *payload_text[] = {
"To: " TO "\r\n",
"From: " /*FROM*/ "Stilottica\r\n",
//"Cc: " CC "Another example User\r\n",
"Subject: ordine lenti\r\n", // subject of tha message
"\r\n", /* empty line to divide headers from body, see RFC5322 */
"Ordine del ", //The body of the message starts here.
// more strings go here
date,
"\r\nA long text email can be very tedious to read."
"\r\n-- end of the message --",
NULL
};
struct upload_status {
int lines_read;
};
static size_t payload_source(void *ptr, size_t size, size_t nmemb, void
*userp)
{
struct upload_status *upload_ctx = (struct upload_status *)userp;
const char *data;
if((size == 0) || (nmemb == 0) || ((size*nmemb) < 1)) {
return 0;
}
data = payload_text[upload_ctx->lines_read];
if(data) {
size_t len = strlen(data);
memcpy(ptr, data, len);
upload_ctx->lines_read++;
return len;
}
return 0;
}
int main(void)
{
CURL *curl;
CURLcode res = CURLE_OK;
struct curl_slist *recipients = NULL;
struct upload_status upload_ctx;
upload_ctx.lines_read = 0;
curl = curl_easy_init();
/* replace xxx with your credentials */
if(curl) {
/* This is the URL for your mailserver */
curl_easy_setopt(curl, CURLOPT_USERNAME, "xxxxxxxxx@xxxxxx.xx"); //
curl_easy_setopt(curl, CURLOPT_PASSWORD, "xxxxxxxx");
curl_easy_setopt(curl, CURLOPT_URL, "xxxxxxxx");
/* Note that this option isn't strictly required, omitting it will
result
* in libcurl sending the MAIL FROM command with empty sender data. All
* autoresponses should have an empty reverse-path, and should be
directed
* to the address in the reverse-path which triggered them. Otherwise,
* they could cause an endless loop. See RFC 5321 Section 4.5.5 for
more
* details.
*/
curl_easy_setopt(curl, CURLOPT_MAIL_FROM, FROM);
/* Add two recipients, in this particular case they correspond to the
* To: and Cc: addressees in the header, but they could be any kind of
* recipient. */
recipients = curl_slist_append(recipients, TO);
//recipients = curl_slist_append(recipients, CC);
curl_easy_setopt(curl, CURLOPT_MAIL_RCPT, recipients);
/* We're using a callback function to specify the payload (the
headers and
* body of the message). You could just use the CURLOPT_READDATA
option to
* specify a FILE pointer to read from. */
curl_easy_setopt(curl, CURLOPT_READFUNCTION, payload_source);
curl_easy_setopt(curl, CURLOPT_READDATA, &upload_ctx);
curl_easy_setopt(curl, CURLOPT_UPLOAD, 1L);
/* Send the message */
res = curl_easy_perform(curl);
/* Check for errors */
if(res != CURLE_OK)
{
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
}
else
{
printf("message sent!");
}
/* Free the list of recipients */
curl_slist_free_all(recipients);
/* curl won't send the QUIT command until you call cleanup, so you
should
* be able to re-use this connection for additional messages (setting
* CURLOPT_MAIL_FROM and CURLOPT_MAIL_RCPT as required, and calling
* curl_easy_perform() again. It may not be a good idea to keep the
* connection open for a very long time though (more than a few minutes
* may result in the server timing out the connection), and you do
want to
* clean up in the end.
*/
curl_easy_cleanup(curl);
}
return (int)res;
}
char *current_date()
{
time_t rawtime;
struct tm *timeinfo = NULL;
char *buf = new char[35];
if(buf == NULL)
{
printf("string allocation error\n");
exit(1);
}
time(&rawtime);
if ((timeinfo = localtime(&rawtime)) == NULL)
{
printf("data generation error");
exit(1);
}
sprintf(buf,"%.2d/%.2d/%4d ore %.2d:%.2d",
timeinfo->tm_mday,
1 + timeinfo->tm_mon,
1900 + timeinfo->tm_year,
timeinfo->tm_hour,
timeinfo->tm_min
);
return buf;
}
|
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 27 05:59PM
On Fri, 2016-02-26, alexo wrote:
> The one he suggested, mimetic, has a bug.
> I'm an absolute beginner on the field but adapting the example code, I
> was able to send with curl my first email from a C/C++ program.
Note that the traditional, safe way of sending an email on Unix is to
pipe it into /usr/lib/sendmail.
But perhaps people don't configure this aspect of their Unix systems
properly these days.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
|
alexo <alelvb@inwind.it>: Feb 27 07:14PM +0100
Il 27/02/2016 13:42, alexo ha scritto:
>> Have you made attempts at debugging?
yes
>> Where does it fail?
on the line that starts data transmission namely,
res = curl_easy_perform(curl);
>> How does it fail?
transmission starts and never ends. Even force closing of the program
wireless activity doesn't stop and always stays on, locking internet
communication.
code of the toy program follows:
in order to make it working you must fill in your username, password and
smtp server address for the outgoing mails.
here in the code:
curl_easy_setopt(curl, CURLOPT_USERNAME, " ");
curl_easy_setopt(curl, CURLOPT_PASSWORD, " ");
curl_easy_setopt(curl, CURLOPT_URL, " ");
/***************************************************************************
* _ _ ____ _
* Project ___| | | | _ \| |
* / __| | | | |_) | |
* | (__| |_| | _ <| |___
* \___|\___/|_| \_\_____|
*
* Copyright (C) 1998 - 2016, Daniel Stenberg, <daniel@haxx.se>, et al.
*
* This software is licensed as described in the file COPYING, which
* you should have received as part of this distribution. The terms
* are also available at https://curl.haxx.se/docs/copyright.html.
*
* You may opt to use, copy, modify, merge, publish, distribute and/or sell
* copies of the Software, and permit persons to whom the Software is
* furnished to do so, under the terms of the COPYING file.
*
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY
OF ANY
* KIND, either express or implied.
*
***************************************************************************/
/* <DESC>
* SMTP example showing how to send e-mails
* </DESC>
*/
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <cstdlib>
#include <curl/curl.h>
/* This is a simple example showing how to send mail using libcurl's SMTP
* capabilities. For an example of using the multi interface please see
* smtp-multi.c.
*
* Note that this example requires libcurl 7.20.0 or above.
*/
#define FROM "<alelvb@inwind.it>"
#define TO "<alessandro.volturno@libero.it>"
//#define CC "<alelvb@inwind.it>"
char *current_date();
char *date = current_date();
static const char *payload_text[] = {
"To: " TO "\r\n",
"From: " /*FROM*/ "Stilottica\r\n",
//"Cc: " CC "Another example User\r\n",
"Subject: ordine lenti\r\n", // subject of tha message
"\r\n", /* empty line to divide headers from body, see RFC5322 */
"Ordine del ", //The body of the message starts here.
// more strings go here
date,
"\r\nA long text email can be very tedious to read."
"\r\n-- end of the message --",
NULL
};
struct upload_status {
int lines_read;
};
static size_t payload_source(void *ptr, size_t size, size_t nmemb, void
*userp)
{
struct upload_status *upload_ctx = (struct upload_status *)userp;
const char *data;
if((size == 0) || (nmemb == 0) || ((size*nmemb) < 1)) {
return 0;
}
data = payload_text[upload_ctx->lines_read];
if(data) {
size_t len = strlen(data);
memcpy(ptr, data, len);
upload_ctx->lines_read++;
return len;
}
return 0;
}
int main(void)
{
CURL *curl;
CURLcode res = CURLE_OK;
struct curl_slist *recipients = NULL;
struct upload_status upload_ctx;
upload_ctx.lines_read = 0;
curl = curl_easy_init();
if(curl) {
/* This is the URL for your mailserver */
curl_easy_setopt(curl, CURLOPT_USERNAME, " ");
curl_easy_setopt(curl, CURLOPT_PASSWORD, " ");
curl_easy_setopt(curl, CURLOPT_URL, " ");
/* Note that this option isn't strictly required, omitting it will
result
* in libcurl sending the MAIL FROM command with empty sender data. All
* autoresponses should have an empty reverse-path, and should be
directed
* to the address in the reverse-path which triggered them. Otherwise,
* they could cause an endless loop. See RFC 5321 Section 4.5.5 for
more
* details.
*/
curl_easy_setopt(curl, CURLOPT_MAIL_FROM, FROM);
/* Add two recipients, in this particular case they correspond to the
* To: and Cc: addressees in the header, but they could be any kind of
* recipient. */
recipients = curl_slist_append(recipients, TO);
//recipients = curl_slist_append(recipients, CC);
curl_easy_setopt(curl, CURLOPT_MAIL_RCPT, recipients);
/* We're using a callback function to specify the payload (the
headers and
* body of the message). You could just use the CURLOPT_READDATA
option to
* specify a FILE pointer to read from. */
curl_easy_setopt(curl, CURLOPT_READFUNCTION, payload_source);
curl_easy_setopt(curl, CURLOPT_READDATA, &upload_ctx);
curl_easy_setopt(curl, CURLOPT_UPLOAD, 1L);
/* Send the message */
res = curl_easy_perform(curl);
/* Check for errors */
if(res != CURLE_OK)
{
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
}
else
{
printf("message sent!");
}
/* Free the list of recipients */
curl_slist_free_all(recipients);
/* curl won't send the QUIT command until you call cleanup, so you
should
* be able to re-use this connection for additional messages (setting
* CURLOPT_MAIL_FROM and CURLOPT_MAIL_RCPT as required, and calling
* curl_easy_perform() again. It may not be a good idea to keep the
* connection open for a very long time though (more than a few minutes
* may result in the server timing out the connection), and you do
want to
* clean up in the end.
*/
curl_easy_cleanup(curl);
}
return (int)res;
}
char *current_date()
{
time_t rawtime;
struct tm *timeinfo = NULL;
char *buf = new char[35];
if(buf == NULL)
{
printf("string allocation error\n");
exit(1);
}
time(&rawtime);
if ((timeinfo = localtime(&rawtime)) == NULL)
{
printf("data generation error");
exit(1);
}
sprintf(buf,"%.2d/%.2d/%4d ore %.2d:%.2d",
timeinfo->tm_mday,
1 + timeinfo->tm_mon,
1900 + timeinfo->tm_year,
timeinfo->tm_hour,
timeinfo->tm_min
);
return buf;
}
|
alexo <alelvb@inwind.it>: Feb 27 07:22PM +0100
Il 27/02/2016 19:14, alexo ha scritto:
> curl_easy_setopt(curl, CURLOPT_USERNAME, " ");
> curl_easy_setopt(curl, CURLOPT_PASSWORD, " ");
> curl_easy_setopt(curl, CURLOPT_URL, " ");
I forgot to specify that it is not the code here reported that fails,
but the same code when I insert it in a callback function to be called
on button pressing.
any help is welcome and appreciated
thank you
|
"Öö Tiib" <ootiib@hot.ee>: Feb 27 10:41AM -0800
On Saturday, 27 February 2016 19:59:33 UTC+2, alexo wrote:
> forever.
> the line that fails is this:
> res = curl_easy_perform(curl);
So your program hangs inside of 'curl_easy_perform' of libcurl.
Where does it "hang"?
How does it "hang"?
Why does it "hang"?
What's it doing at the time of "hanging"?
|
Paavo Helde <myfirstname@osa.pri.ee>: Feb 27 09:46PM +0200
On 27.02.2016 19:59, alexo wrote:
> when I insert this code in my program,
> This code being called by pressing a button on the GUI transmission goes
> forever.
Obviously your two programs differ in some sense, as one is working as
expected and the other does not. Obviously you have made changes when
pasting the code to your real program (otherwise you would have two
main() functions which would not compile).
You have to figure out what is the crucial difference. And no, posting
the code for the *working* program is not very helpful. Instead, you
should extract the minimal *non-working* program from your real app.
According to your claims the program is sending infinite amount of data.
However, the data is provided by your own callback function
(payload_source()), so you could easily put a breakpoint there and find
out how much and what data it is sending.
|
legalize+jeeves@mail.xmission.com (Richard): Feb 27 12:54AM
[Please do not mail me a copy of your followup]
Lynn McGuire <lmc@winsim.com> spake the secret code
>There is not a standard user interface toolkit proposal.
Don't need it.
There are already several good defacto standards: Qt, wxWidgets, and
(less to my personal taste, but relevant) MFC. Where "good" is defined
from various perspectives including, but not limited to, freely available,
actively improved, proven viability in the marketplace and portable among
platforms.
C doesn't have it.
Python doesn't have it.
JavaScript doesn't have it.
NodeJS doesn't have it.
FORTRAN doesn't have it.
Java doesn't have it.
C# doesn't have it.
Why people are insistent on trying to jam every possible library into
the standard is beyond me. Before trying to make the C++ Standard
Library the union of all available libraries on the internet, how
about we sovle the dependency and package system in a reasonable way?
Hell, how about we get modules deployed and widely used?
Either of those is way more fucking[*] important than a UI library in
the standard.
[*] This one's for you, woodbrain77.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
|
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 27 05:19AM +0100
On 27.02.2016 01:54, Richard wrote:
> actively improved, proven viability in the marketplace and portable among
> platforms.
> C doesn't have it.
Right.
> Python doesn't have it.
Well, CPython ships with Tk/Inter (I think it was called). Which is
standard in the sense that it's always there, as a basic GUI.
> JavaScript doesn't have it.
Oh, for JavaScript it's just HTML.
> NodeJS doesn't have it.
An embarrassment of riches. First of course basic HTML, both on the web,
in web apps (including Android phone apps), and e.g. Windows HTML
applications (old but still going technology). But then also the two
variants of whatever it was called, that was used to build the editor,
that the Microsoft "Code" editor is based on (and still uses that).
Sorry I'm not more clear on this. I could research it. In fact that's
the plan, but I'm not there yet. :(
> FORTRAN doesn't have it.
> Java doesn't have it.
Well, at first Java had AWT, and then Swing built on AWT. At which
point, as I recall, they changed the namespaces, breaking lots and lots
of code. Infuriating.
> C# doesn't have it.
C# is like NodeJS, just too many GUI toolkits now. But the main basic C#
GUI stuff is Windows Forms. I believe Mono has Windows Forms support?
> Library the union of all available libraries on the internet, how
> about we sovle the dependency and package system in a reasonable way?
> Hell, how about we get modules deployed and widely used?
Good ideas all, I agree.
And there is already experimental support for modules in Visual C++.
Which reminds me to try that out! :)
But I think that one should start at the absolutely first little thing
that one needs to deal with to do C++ programming. And that is of course
the `main` function. Happily Microsoft recently informed me they'll fix
their lack of direct support for standard `main` in GUI subsystem
programs, in some forthcoming release. Well, at least I chose to
interpret the wording that way. But [1]judge for yourself. :)
Then, I think it would be nice to get basic type support in place, in
particular character encoding value types and ditto string literals, as
in my work-in-progress [2]cppx library, or thereabouts. Well not just
international text handling support, but also, hm, dates!, and a decimal
type sufficient for handling national scale monetary amounts, and,
little things like getting -- for Pete's sake -- [3]a `std::pi` constant!
It's all the little stuff that makes the language usable.
Having each project and person reinvent the wheel again and again and
again, is IMHO sub-optimal. Well the Poco library does some of this. But
for some reason I've never used Poco -- have any reader?
> Either of those is way more [expletive removed] important than a UI
> library in the standard.
Yes I agree. :)
Cheers!,
- Alf
Notes:
[1] <url:
https://connect.microsoft.com/VisualStudio/feedback/details/2128262/missing-c-11-standard-macro-stdc-hosted>
[2] <url: http://alf-p-steinbach.github.io/cppx/>
[3] `M_PI` is already de facto standard, but not part of the C++
standard. It surprised me, once, to realize how much innovation the
committee's been doing, while /not/ standardizing widely used existing
practice. Anyway, more info: <url:
http://stackoverflow.com/questions/1727881/how-to-use-the-pi-constant-in-c>
|
David Brown <david.brown@hesbynett.no>: Feb 27 02:41PM +0100
On 27/02/16 05:19, Alf P. Steinbach wrote:
>> Hell, how about we get modules deployed and widely used?
> Good ideas all, I agree.
> And there is already experimental support for modules in Visual C++.
Unfortunately, I think they are significantly different from the
experimental modules in clang. I wish they would get this one sorted
out, so that we can have a single proper module feature for C++.
|
"Öö Tiib" <ootiib@hot.ee>: Feb 27 08:45AM -0800
On Saturday, 27 February 2016 15:41:31 UTC+2, David Brown wrote:
> Unfortunately, I think they are significantly different from the
> experimental modules in clang. I wish they would get this one sorted
> out, so that we can have a single proper module feature for C++.
Experimental implementation is not carved into rock and its makers
knew that it has to be likely rewritten. People who used such for
real product knew with what they risk.
I am more worried that adding innovations like Modules, Concepts and
Reflection at once will cause serious headache of integrating those
features into whole.
|
Dombo <dombo@disposable.invalid>: Feb 27 07:41PM +0100
Op 27-Feb-16 om 5:19 schreef Alf P. Steinbach:
>> from various perspectives including, but not limited to, freely
>> available, actively improved, proven viability in the marketplace and portable among
>> platforms.
Unfortunately those user interface kits are showing their age; they
don't take advantage of modern C++ features but instead choose to supply
their own string, container...etc classes and mechanisms. All of this
was understandable in the nineties before C++ was standardized but is
unforgivable in this day and age.
It would be nice to have a multi platform widely used GUI toolkit that
takes advantage of modern C++ and that smoothly interfaces with the
standard library.
[snip]
>> C# doesn't have it.
> C# is like NodeJS, just too many GUI toolkits now. But the main basic C#
> GUI stuff is Windows Forms. I believe Mono has Windows Forms support?
Development of WinForms has stopped well over a decade ago, nowadays WPF
is pretty much the way to go. Besides those two I don't know of any
other widely used GUI toolkit in the .NET world.
|
"Öö Tiib" <ootiib@hot.ee>: Feb 27 11:23AM -0800
On Saturday, 27 February 2016 20:41:05 UTC+2, Dombo wrote:
> their own string, container...etc classes and mechanisms. All of this
> was understandable in the nineties before C++ was standardized but is
> unforgivable in this day and age.
It is actually good. It makes clear interface where your program logic
layer (that does not use UI classes) touches with UI (that does not
use standard library).
Standard C++ has weak and full of "implementation-defined" features
regarding unicode, locales etc. This day and age we have to either:
a) accept having files with names full of garbage, show different
garbage instead of text on each platform and also format numbers
(nothing to talk of money, date and time) in unpredictable way;
b) write significant amount of portability code to deal with it;
c) use platform-specific API calls;
d) use those QStrings and QLocales that already deal with it.
> It would be nice to have a multi platform widely used GUI toolkit that
> takes advantage of modern C++ and that smoothly interfaces with the
> standard library.
I like harshly interfacing GUI. I dislike code where program logic is
intermixed with GUI and I congratulate GUI toolkit that makes it as
painful as possible for those who let so different responsibilities
to diffuse all over the code base.
|
Les Cargill <lcargill99@comcast.com>: Feb 26 07:07PM -0600
David Brown wrote:
>> 'C' so you have to test it.
> No, endianness is not remotely "undefined behaviour" - it is
> /implementation/ defined behaviour. There is a huge difference.
Ah, there you go. Right! I'd forgotten the term of art.
<snip>
--
Les Cargill
|
Allan Herriman <allanherriman@hotmail.com>: Feb 27 08:58AM
On Fri, 26 Feb 2016 17:09:37 +0100, David Brown wrote:
> compiler - so it is not going to happen. (I know of only one case where
> this happened - and that was on MS's x86 compiler, a long time ago,
> where they changed the bitfield endianness.)
It happened to me on an 8051 C compiler in the '90s. The endianness of
bitfields changed between one compiler version and the next.
I learned a lesson, and have not used bitfields in C since then.
I believe the compiler vendor is still in business today (well, they were
bought by a microcontroller manufacturer).
Regards,
Allan
|
David Brown <david.brown@hesbynett.no>: Feb 27 02:37PM +0100
On 27/02/16 09:58, Allan Herriman wrote:
>> where they changed the bitfield endianness.)
> It happened to me on an 8051 C compiler in the '90s. The endianness of
> bitfields changed between one compiler version and the next.
Thanks - now I know of /two/ cases where compilers have changed bit
ordering!
> I learned a lesson, and have not used bitfields in C since then.
You are throwing out the baby with the bathwater. If you avoid using a
feature just because a small-time compiler writer for a brain-dead and
C-unfriendly processor made an inconvenient decision two decades ago,
you would have to give up programming altogether. Bitfields have
portability issues, but can be extremely useful - they are perfectly
safe to use once you understand them.
|
"Öö Tiib" <ootiib@hot.ee>: Feb 27 07:21AM -0800
On Saturday, 27 February 2016 15:37:59 UTC+2, David Brown wrote:
> you would have to give up programming altogether. Bitfields have
> portability issues, but can be extremely useful - they are perfectly
> safe to use once you understand them.
+1. Not only small-time. All the versions of "big-time" compilers have
been defective in one or other way. There are only (more or less)
defective tools and libraries and platforms. Getting the work done
with such is part of skill. Without desire to acquire that skill it
is impossible to make software.
|
David Brown <david.brown@hesbynett.no>: Feb 27 04:34PM +0100
On 27/02/16 16:21, 嘱 Tiib wrote:
> defective tools and libraries and platforms. Getting the work done
> with such is part of skill. Without desire to acquire that skill it
> is impossible to make software.
Changing the bitfield order between versions is not really a "defect" as
such - it's a design decision, not a bug. When MS did it (and I guess
they count as "big-time"), they moved to little-endian ordering because
it was much more common for other tools on the x86 and other
little-endian processors. So it was a good decision, but it came as a
surprise to people who had upgrade compiler versions and found their
code changed functionality.
But yes, even "big-time" compilers have bugs. Some, like gcc and clang,
are very open about them - some others prefer to keep them secret until
you open a support case (I don't mean to imply that all closed-source
compiler manufacturers keep their bugs secret, as that would be far from
true). It seems there is little relationship between the cost of tools
and their quality. Certainly the last compiler bugs I have seen have
been in very expensive, big-name tools for a brain-dead microcontroller.
Those bugs turned up on simple, clear code - nothing complicated or
bleeding-edge. (I would prefer not to name the tools as I have only
helped out another developer here, rather than studying the tool in detail.)
|
"Öö Tiib" <ootiib@hot.ee>: Feb 27 10:14AM -0800
On Saturday, 27 February 2016 17:35:00 UTC+2, David Brown wrote:
> little-endian processors. So it was a good decision, but it came as a
> surprise to people who had upgrade compiler versions and found their
> code changed functionality.
I meant it more generally. People who ever want to port their code to
different version or different compiler or different platform should
be prepared that there are some noisy and some silent breaking changes.
Some are because of implementation-defined features like that binary
representation of bitfield some are because of defects. Defects are
most likely in the code compiled but sometimes also in previous or
new implementation.
> Those bugs turned up on simple, clear code - nothing complicated or
> bleeding-edge. (I would prefer not to name the tools as I have only
> helped out another developer here, rather than studying the tool in detail.)
Such things happen rarely may be 1-3 times a year but I have also feeling
that if a tool costs like $2K or more per license then it is a warning
sign about potential quality issues.
|
