Skip to content

String(negativeInteger, HEX) doesn't return the same thing than with an Arduino UNO. #2813

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pierrepoulpe opened this issue Dec 29, 2016 · 3 comments

Comments

@pierrepoulpe
Copy link

Basic Infos

Hardware

Hardware: NodeMCU ESP-12E
Core Version: 2.3.0

Description

String(negativeInteger, HEX) doesn't return the same thing than with an Arduino UNO.

Settings in IDE

Module: NodeMCU 1.0
Flash Size: 4MB/3MB
CPU Frequency: 80Mhz
Upload Using: SERIAL
Reset Method: nodemcu

Sketch

long a;

void setup() {
  // put your setup code here, to run once:
  a = -100;
  delay(500);
  Serial.begin(9600);
  Serial.println(String(a,HEX));
  

}

void loop() {
  // put your main code here, to run repeatedly:

}

Serial Output

-64

Exact same code, uploaded to UNO

ffffff9c

Strange, isn't it? I supposed String library was platform independant... I was wrong.

Uno version sounds better to me....

@devyte
Copy link
Collaborator

devyte commented Oct 5, 2017

@pierrepoulpe is this still an issue in latest git? I think the correct output should be what you get for the UNO.

@devyte devyte added the waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. label Oct 5, 2017
@earlephilhower earlephilhower added type: bug component: core and removed waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. labels Jan 16, 2019
@earlephilhower earlephilhower added this to the 2.6.0 milestone Jan 16, 2019
@earlephilhower
Copy link
Collaborator

This is a bug.

Our ltoa doesn't behave correctly for negative, non base10 #s. It should be safe to replace the shim functions in core_esp8266_noniso.c with calls to itoa and utoa since long and int are the same size.

earlephilhower added a commit to earlephilhower/Arduino that referenced this issue Jan 16, 2019
Use the newlib integer-to-ASCII non-POSIX calls instead of rolling
our own.  Should be safe as sizeof(long) == sizeof(int).
The custom functions behaved differently from itoa when passed in
negative values in non-base-10.

Fixes bug esp8266#2813
@earlephilhower
Copy link
Collaborator

Fixed with #5625

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants